Loading ...
Sorry, an error occurred while loading the content.

Patch 7.3.582

Expand Messages
  • Bram Moolenaar
    Patch 7.3.582 (after 7.3.576) Problem: Missing parts of the test OK file. Solution: Add the missing parts. Files: src/testdir/test68.ok ...
    Message 1 of 15 , Jun 29, 2012
    • 0 Attachment
      Patch 7.3.582 (after 7.3.576)
      Problem: Missing parts of the test OK file.
      Solution: Add the missing parts.
      Files: src/testdir/test68.ok


      *** ../vim-7.3.581/src/testdir/test68.ok 2012-06-13 17:28:51.000000000 +0200
      --- src/testdir/test68.ok 2012-06-29 15:00:13.000000000 +0200
      ***************
      *** 35,40 ****
      --- 35,48 ----


      {
      + 1 a
      + b
      + # 1 a
      + # b
      + }
      +
      +
      + {
      # 1 a
      # b
      }
      ***************
      *** 48,50 ****
      --- 56,62 ----

      { 1aa ^^2bb }

      +
      + # 1 xxxxx
      + # foobar
      +
      *** ../vim-7.3.581/src/version.c 2012-06-29 19:14:48.000000000 +0200
      --- src/version.c 2012-06-29 23:57:43.000000000 +0200
      ***************
      *** 716,717 ****
      --- 716,719 ----
      { /* Add new patch number below this line */
      + /**/
      + 582,
      /**/

      --
      If your nose runs, and your feet smell, you might be upside down.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • Cesar Romani
      I m building vim on windows 7 with MinGW. By upgrading from 7.3.566 to ... ... os_win32.c: In function mch_avail_mem : os_win32.c:5012:2: error: unknown type
      Message 2 of 15 , Jun 29, 2012
      • 0 Attachment
        I'm building vim on windows 7 with MinGW. By upgrading from 7.3.566 to
        7.3.582 I get the following compile error:

        -------------------
        ...
        os_win32.c: In function 'mch_avail_mem':
        os_win32.c:5012:2: error: unknown type name 'MEMORYSTATUSEX'
        os_win32.c:5014:4: error: request for member 'dwLength' in something not
        a structure or union
        os_win32.c:5014:23: error: 'MEMORYSTATUSEX' undeclared (first use in
        this function)
        os_win32.c:5014:23: note: each undeclared identifier is reported only
        once for each function it appears in
        os_win32.c:5016:21: error: request for member 'ullAvailPhys' in
        something not a structure or union
        os_win32.c:5016:39: error: request for member 'ullAvailPageFile' in
        something not a structure or union
        make: *** [gobjZ/os_win32.o] Error 1
        Error by compiling gvim.exe
        --------------------

        Many thanks in advance,

        --
        Cesar

        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • Christian J. Robinson
        ... I can confirm this; although I m using Make_cyg.mak, I get some of the same error(s): os_win32.c:157: warning: initialization from incompatible pointer
        Message 3 of 15 , Jun 29, 2012
        • 0 Attachment
          On Fri, 29 Jun 2012, Cesar Romani wrote:

          > I'm building vim on windows 7 with MinGW. By upgrading from 7.3.566
          > to 7.3.582 I get the following compile error:

          I can confirm this; although I'm using Make_cyg.mak, I get some of the
          same error(s):

          os_win32.c:157: warning: initialization from incompatible pointer type
          os_win32.c: In function `sub_process_writer':
          os_win32.c:3410: warning: passing arg 4 of `WriteFile' from incompatible pointer type
          os_win32.c: In function `mch_avail_mem':
          os_win32.c:5012: error: `MEMORYSTATUSEX' undeclared (first use in this function)
          os_win32.c:5012: error: (Each undeclared identifier is reported only once
          os_win32.c:5012: error: for each function it appears in.)
          os_win32.c:5012: error: parse error before "ms"
          os_win32.c:5014: error: `ms' undeclared (first use in this function)
          Make_cyg.mak:585: recipe for target `gobj/os_win32.o' failed
          make: *** [gobj/os_win32.o] Error 1

          --
          "It's a dangerous business going out your front door." -- J.R.R. Tolkien
          Christian J. Robinson <heptite@...> http://christianrobinson.name/

          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • Bram Moolenaar
          ... Is that the latest version of MingW? MEMORYSTATUSEX is a standard part of Windows XP and later. Hmm, I found a suggestion to put this before including
          Message 4 of 15 , Jun 30, 2012
          • 0 Attachment
            Cesar Romani wrote:

            > I'm building vim on windows 7 with MinGW. By upgrading from 7.3.566 to
            > 7.3.582 I get the following compile error:
            >
            > -------------------
            > ...
            > os_win32.c: In function 'mch_avail_mem':
            > os_win32.c:5012:2: error: unknown type name 'MEMORYSTATUSEX'
            > os_win32.c:5014:4: error: request for member 'dwLength' in something not
            > a structure or union
            > os_win32.c:5014:23: error: 'MEMORYSTATUSEX' undeclared (first use in
            > this function)
            > os_win32.c:5014:23: note: each undeclared identifier is reported only
            > once for each function it appears in
            > os_win32.c:5016:21: error: request for member 'ullAvailPhys' in
            > something not a structure or union
            > os_win32.c:5016:39: error: request for member 'ullAvailPageFile' in
            > something not a structure or union
            > make: *** [gobjZ/os_win32.o] Error 1
            > Error by compiling gvim.exe
            > --------------------
            >
            > Many thanks in advance,

            Is that the latest version of MingW? MEMORYSTATUSEX is a standard part
            of Windows XP and later.

            Hmm, I found a suggestion to put this before including windows.h:

            #define _WIN32_WINNT 0x0501

            We have never needed that for other features, thus I doubt that is the
            right solution.

            We could use #ifdef MEMORYSTATUSEX, but is it really a #define in all
            header files?

            --
            hundred-and-one symptoms of being an internet addict:
            89. In addition to your e-mail address being on your business
            cards you even have your own domain.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ an exciting new programming language -- http://www.Zimbu.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • Chris Sutcliffe
            ... It is the one possible solution, MEMORYSTATUSEX is defined by the mingw.org compiler in winbase.h which is included by windows.h, and looking at the
            Message 5 of 15 , Jun 30, 2012
            • 0 Attachment
              On 30 June 2012 07:17, Bram Moolenaar wrote:
              > Is that the latest version of MingW? MEMORYSTATUSEX is a standard part
              > of Windows XP and later.
              >
              > Hmm, I found a suggestion to put this before including windows.h:
              >
              > #define _WIN32_WINNT 0x0501
              >
              > We have never needed that for other features, thus I doubt that is the
              > right solution.

              It is the one possible solution, MEMORYSTATUSEX is defined by the
              mingw.org compiler in winbase.h which is included by windows.h, and
              looking at the definition:

              #if (_WIN32_WINNT >= 0x0500)
              typedef struct _MEMORYSTATUSEX {
              DWORD dwLength;
              DWORD dwMemoryLoad;
              DWORDLONG ullTotalPhys;
              DWORDLONG ullAvailPhys;
              DWORDLONG ullTotalPageFile;
              DWORDLONG ullAvailPageFile;
              DWORDLONG ullTotalVirtual;
              DWORDLONG ullAvailVirtual;
              DWORDLONG ullAvailExtendedVirtual;
              } MEMORYSTATUSEX,*LPMEMORYSTATUSEX;
              #endif

              The current w32api provided by mingw.org defines _WIN32_WINNT as
              WINVER and WINVER is defined as 0x0400, so it won't pick up this
              struct.

              Another way this could be handled is by define _WIN32_WINNT in the
              .mak files. In fact in the Make_ming.mak file WINVER is defined as:

              # Set the default $(WINVER) to make it work with pre-Win2k
              ifndef WINVER
              WINVER = 0x0400
              endif

              So adjusting it in the source would be ineffective anyway, you should
              just adjust WINVER in Make_ming.mak.

              Cheers,

              Chris

              --
              Chris Sutcliffe
              http://emergedesktop.org
              http://www.google.com/profiles/ir0nh34d

              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            • Bram Moolenaar
              ... If we can solve it by changing the default for WINVER to 0x0500 that should probably work. Still, there is quite a large uncertainty about what the side
              Message 6 of 15 , Jun 30, 2012
              • 0 Attachment
                Chris Sutcliffe wrote:

                > On 30 June 2012 07:17, Bram Moolenaar wrote:
                > > Is that the latest version of MingW? MEMORYSTATUSEX is a standard part
                > > of Windows XP and later.
                > >
                > > Hmm, I found a suggestion to put this before including windows.h:
                > >
                > > #define _WIN32_WINNT 0x0501
                > >
                > > We have never needed that for other features, thus I doubt that is the
                > > right solution.
                >
                > It is the one possible solution, MEMORYSTATUSEX is defined by the
                > mingw.org compiler in winbase.h which is included by windows.h, and
                > looking at the definition:
                >
                > #if (_WIN32_WINNT >= 0x0500)
                > typedef struct _MEMORYSTATUSEX {
                > DWORD dwLength;
                > DWORD dwMemoryLoad;
                > DWORDLONG ullTotalPhys;
                > DWORDLONG ullAvailPhys;
                > DWORDLONG ullTotalPageFile;
                > DWORDLONG ullAvailPageFile;
                > DWORDLONG ullTotalVirtual;
                > DWORDLONG ullAvailVirtual;
                > DWORDLONG ullAvailExtendedVirtual;
                > } MEMORYSTATUSEX,*LPMEMORYSTATUSEX;
                > #endif
                >
                > The current w32api provided by mingw.org defines _WIN32_WINNT as
                > WINVER and WINVER is defined as 0x0400, so it won't pick up this
                > struct.
                >
                > Another way this could be handled is by define _WIN32_WINNT in the
                > .mak files. In fact in the Make_ming.mak file WINVER is defined as:
                >
                > # Set the default $(WINVER) to make it work with pre-Win2k
                > ifndef WINVER
                > WINVER = 0x0400
                > endif
                >
                > So adjusting it in the source would be ineffective anyway, you should
                > just adjust WINVER in Make_ming.mak.

                If we can solve it by changing the default for WINVER to 0x0500 that
                should probably work. Still, there is quite a large uncertainty about
                what the side effects are.

                I would really appreciate it if a few people try out the solution for
                changing WINVER on different systems.

                --
                From "know your smileys":
                :^[/ mean-smiley-with-cigarette

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ an exciting new programming language -- http://www.Zimbu.org ///
                \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
              • Chris Sutcliffe
                ... One of the side affects of using a function this is only available in XP and above is that Vim will no longer work on Win2K. Chris -- Chris Sutcliffe
                Message 7 of 15 , Jun 30, 2012
                • 0 Attachment
                  On 30 June 2012 10:22, Bram Moolenaar wrote:
                  >> So adjusting it in the source would be ineffective anyway, you should
                  >> just adjust WINVER in Make_ming.mak.
                  >
                  > If we can solve it by changing the default for WINVER to 0x0500 that
                  > should probably work. Still, there is quite a large uncertainty about
                  > what the side effects are.

                  One of the side affects of using a function this is only available in
                  XP and above is that Vim will no longer work on Win2K.

                  Chris

                  --
                  Chris Sutcliffe
                  http://emergedesktop.org
                  http://www.google.com/profiles/ir0nh34d

                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php
                • Christian J. Robinson
                  ... This allowed gvim to compile for me using Make_cyg.mak: make -f Make_cyg.mak WINVER=0x0500 [...] (I haven t been able to get Make_ming.mak to work.) -
                  Message 8 of 15 , Jun 30, 2012
                  • 0 Attachment
                    On Sat, 30 Jun 2012, Bram Moolenaar wrote:

                    > If we can solve it by changing the default for WINVER to 0x0500 that
                    > should probably work. Still, there is quite a large uncertainty
                    > about what the side effects are.
                    >
                    > I would really appreciate it if a few people try out the solution
                    > for changing WINVER on different systems.

                    This allowed gvim to compile for me using Make_cyg.mak:
                    make -f Make_cyg.mak WINVER=0x0500 [...]

                    (I haven't been able to get Make_ming.mak to work.)

                    - Christian

                    --
                    "I don't necessarily agree with everything I say." -- Marshall McLuhan
                    Christian J. Robinson <heptite@...> http://christianrobinson.name/

                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php
                  • Raymond Ko
                    ... This is quite odd, as I can can compile latest trunk fine without having to change WINVER or _WIN32_WINNT. I am using MinGW 4.7.1 from:
                    Message 9 of 15 , Jun 30, 2012
                    • 0 Attachment
                      On Saturday, June 30, 2012 12:33:05 PM UTC-4, Heptite wrote:
                      > On Sat, 30 Jun 2012, Bram Moolenaar wrote:
                      >
                      > > If we can solve it by changing the default for WINVER to 0x0500 that
                      > > should probably work. Still, there is quite a large uncertainty
                      > > about what the side effects are.
                      > >
                      > > I would really appreciate it if a few people try out the solution
                      > > for changing WINVER on different systems.
                      >
                      > This allowed gvim to compile for me using Make_cyg.mak:
                      > make -f Make_cyg.mak WINVER=0x0500 [...]
                      >
                      > (I haven't been able to get Make_ming.mak to work.)
                      >
                      > - Christian
                      >
                      > --
                      > "I don't necessarily agree with everything I say." -- Marshall McLuhan
                      > Christian J. Robinson <heptite@...> http://christianrobinson.name/

                      This is quite odd, as I can can compile latest trunk fine without having to change WINVER or _WIN32_WINNT.

                      I am using MinGW 4.7.1 from:
                      http://sourceforge.net/projects/mingwbuilds/files/windows-host/

                      Custom Compilation Batch File:
                      @echo off
                      pushd %~dp0

                      set PATH=C:\MinGW32\bin;C:\Perl\bin
                      mingw32-make -f Make_ming.mak clean
                      mingw32-make -f Make_ming.mak
                      strip --strip-all gvim.exe
                      strip --strip-all vimrun.exe
                      strip --strip-all xxd\xxd.exe

                      C:\Windows\System32\xcopy.exe /y /f gvim.exe "C:\Program Files (x86)\Vim\vim73\"
                      C:\Windows\System32\xcopy.exe /y /f vimrun.exe "C:\Program Files (x86)\Vim\vim73\"
                      C:\Windows\System32\xcopy.exe /y /f xxd\xxd.exe "C:\Program Files (x86)\Vim\vim73\"

                      Diff of my Make_mingw.mak versus trunk, nothing special, just selection options and flags:

                      35c35
                      < FEATURES=BIG
                      ---
                      > FEATURES=HUGE
                      37c37
                      < ARCH=i386
                      ---
                      > ARCH=native
                      50c50
                      < POSTSCRIPT=no
                      ---
                      > POSTSCRIPT=yes
                      52c52
                      < OLE=no
                      ---
                      > OLE=yes
                      66c66
                      < STATIC_STDCPLUS=no
                      ---
                      > STATIC_STDCPLUS=yes
                      102c102
                      < #PERL=C:/perl
                      ---
                      > PERL=C:/perl
                      105c105
                      < PERL_VER=56
                      ---
                      > PERL_VER=514
                      125c125
                      < #LUA=/usr/local
                      ---
                      > LUA=C:/Lua51
                      197c197
                      < #PYTHON=c:/python20
                      ---
                      > PYTHON=C:/Python27
                      205c205
                      < PYTHON_VER=22
                      ---
                      > PYTHON_VER=27
                      220a221
                      > PYTHON3=C:/Python32
                      228c229
                      < PYTHON3_VER=31
                      ---
                      > PYTHON3_VER=32
                      246c247
                      < #TCL=c:/tcl
                      ---
                      > TCL=c:/Tcl
                      252c253
                      < TCL_VER = 83
                      ---
                      > TCL_VER = 85
                      264c265
                      < #RUBY=c:/ruby
                      ---
                      > RUBY=c:/Ruby193
                      271c272
                      < RUBY_VER = 16
                      ---
                      > RUBY_VER = 191
                      274c275
                      < RUBY_VER_LONG = 1.6
                      ---
                      > RUBY_VER_LONG = 1.9.1
                      308a310
                      > DEFINES += -DHAVE_STRUCT_TIMESPEC -DHAVE_STRUCT_TIMEZONE
                      444,445c446,447
                      < CFLAGS += -O3
                      < CFLAGS += -fomit-frame-pointer -freg-struct-return
                      ---
                      > CFLAGS += -O2
                      > CFLAGS += -flto -fuse-linker-plugin -fwhole-program

                      --
                      You received this message from the "vim_dev" maillist.
                      Do not top-post! Type your reply below the text you are replying to.
                      For more information, visit http://www.vim.org/maillist.php
                    • Bram Moolenaar
                      ... There is a runtime check for the system version. Using the old version for old systems. -- ... /// Bram Moolenaar -- Bram@Moolenaar.net --
                      Message 10 of 15 , Jun 30, 2012
                      • 0 Attachment
                        Chris Sutcliffe wrote:

                        > On 30 June 2012 10:22, Bram Moolenaar wrote:
                        > >> So adjusting it in the source would be ineffective anyway, you should
                        > >> just adjust WINVER in Make_ming.mak.
                        > >
                        > > If we can solve it by changing the default for WINVER to 0x0500 that
                        > > should probably work. Still, there is quite a large uncertainty about
                        > > what the side effects are.
                        >
                        > One of the side affects of using a function this is only available in
                        > XP and above is that Vim will no longer work on Win2K.

                        There is a runtime check for the system version. Using the old version
                        for old systems.

                        --
                        From "know your smileys":
                        :----} You lie like Pinocchio

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                        \\\ an exciting new programming language -- http://www.Zimbu.org ///
                        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                        --
                        You received this message from the "vim_dev" maillist.
                        Do not top-post! Type your reply below the text you are replying to.
                        For more information, visit http://www.vim.org/maillist.php
                      • Charles
                        ... Using Visual C++ 2010 in XP and WINVER=0x500, find / replace dialogs do not work (the commands just fail silently). As an alternative, we can load
                        Message 11 of 15 , Jul 1, 2012
                        • 0 Attachment
                          On Sat, Jun 30, 2012 at 9:22 PM, Bram Moolenaar <Bram@...> wrote:
                          >
                          > Chris Sutcliffe wrote:
                          >
                          >> On 30 June 2012 07:17, Bram Moolenaar wrote:
                          >> > Is that the latest version of MingW? MEMORYSTATUSEX is a standard part
                          >> > of Windows XP and later.
                          >> >
                          >> > Hmm, I found a suggestion to put this before including windows.h:
                          >> >
                          >> > #define _WIN32_WINNT 0x0501
                          >> >
                          >> > We have never needed that for other features, thus I doubt that is the
                          >> > right solution.
                          >>
                          >> It is the one possible solution, MEMORYSTATUSEX is defined by the
                          >> mingw.org compiler in winbase.h which is included by windows.h, and
                          >> looking at the definition:
                          >>
                          >> #if (_WIN32_WINNT >= 0x0500)
                          >> typedef struct _MEMORYSTATUSEX {
                          >> DWORD dwLength;
                          >> DWORD dwMemoryLoad;
                          >> DWORDLONG ullTotalPhys;
                          >> DWORDLONG ullAvailPhys;
                          >> DWORDLONG ullTotalPageFile;
                          >> DWORDLONG ullAvailPageFile;
                          >> DWORDLONG ullTotalVirtual;
                          >> DWORDLONG ullAvailVirtual;
                          >> DWORDLONG ullAvailExtendedVirtual;
                          >> } MEMORYSTATUSEX,*LPMEMORYSTATUSEX;
                          >> #endif
                          >>
                          >> The current w32api provided by mingw.org defines _WIN32_WINNT as
                          >> WINVER and WINVER is defined as 0x0400, so it won't pick up this
                          >> struct.
                          >>
                          >> Another way this could be handled is by define _WIN32_WINNT in the
                          >> .mak files. In fact in the Make_ming.mak file WINVER is defined as:
                          >>
                          >> # Set the default $(WINVER) to make it work with pre-Win2k
                          >> ifndef WINVER
                          >> WINVER = 0x0400
                          >> endif
                          >>
                          >> So adjusting it in the source would be ineffective anyway, you should
                          >> just adjust WINVER in Make_ming.mak.
                          >
                          > If we can solve it by changing the default for WINVER to 0x0500 that
                          > should probably work. Still, there is quite a large uncertainty about
                          > what the side effects are.
                          >
                          > I would really appreciate it if a few people try out the solution for
                          > changing WINVER on different systems.

                          Using Visual C++ 2010 in XP and WINVER=0x500, find / replace dialogs
                          do not work (the commands just fail silently).

                          As an alternative, we can load kernel32.dll and bind the memory
                          address of MemoryStatusEx. If it isn't found, then fallback to
                          MemoryStatus, thus eliminating the requirement of changing WINVER.

                          --
                          You received this message from the "vim_dev" maillist.
                          Do not top-post! Type your reply below the text you are replying to.
                          For more information, visit http://www.vim.org/maillist.php
                        • Bram Moolenaar
                          ... Setting WINVER to 0x0500 is needed at compile time. The idea was to set the default in Make_ming.mak and Make_cyg.mak, thus Visual C++ is unaffected. --
                          Message 12 of 15 , Jul 1, 2012
                          • 0 Attachment
                            Charles wrote:

                            > On Sat, Jun 30, 2012 at 9:22 PM, Bram Moolenaar <Bram@...> wrote:
                            > >
                            > > Chris Sutcliffe wrote:
                            > >
                            > >> On 30 June 2012 07:17, Bram Moolenaar wrote:
                            > >> > Is that the latest version of MingW? MEMORYSTATUSEX is a standard part
                            > >> > of Windows XP and later.
                            > >> >
                            > >> > Hmm, I found a suggestion to put this before including windows.h:
                            > >> >
                            > >> > #define _WIN32_WINNT 0x0501
                            > >> >
                            > >> > We have never needed that for other features, thus I doubt that is the
                            > >> > right solution.
                            > >>
                            > >> It is the one possible solution, MEMORYSTATUSEX is defined by the
                            > >> mingw.org compiler in winbase.h which is included by windows.h, and
                            > >> looking at the definition:
                            > >>
                            > >> #if (_WIN32_WINNT >= 0x0500)
                            > >> typedef struct _MEMORYSTATUSEX {
                            > >> DWORD dwLength;
                            > >> DWORD dwMemoryLoad;
                            > >> DWORDLONG ullTotalPhys;
                            > >> DWORDLONG ullAvailPhys;
                            > >> DWORDLONG ullTotalPageFile;
                            > >> DWORDLONG ullAvailPageFile;
                            > >> DWORDLONG ullTotalVirtual;
                            > >> DWORDLONG ullAvailVirtual;
                            > >> DWORDLONG ullAvailExtendedVirtual;
                            > >> } MEMORYSTATUSEX,*LPMEMORYSTATUSEX;
                            > >> #endif
                            > >>
                            > >> The current w32api provided by mingw.org defines _WIN32_WINNT as
                            > >> WINVER and WINVER is defined as 0x0400, so it won't pick up this
                            > >> struct.
                            > >>
                            > >> Another way this could be handled is by define _WIN32_WINNT in the
                            > >> .mak files. In fact in the Make_ming.mak file WINVER is defined as:
                            > >>
                            > >> # Set the default $(WINVER) to make it work with pre-Win2k
                            > >> ifndef WINVER
                            > >> WINVER = 0x0400
                            > >> endif
                            > >>
                            > >> So adjusting it in the source would be ineffective anyway, you should
                            > >> just adjust WINVER in Make_ming.mak.
                            > >
                            > > If we can solve it by changing the default for WINVER to 0x0500 that
                            > > should probably work. Still, there is quite a large uncertainty about
                            > > what the side effects are.
                            > >
                            > > I would really appreciate it if a few people try out the solution for
                            > > changing WINVER on different systems.
                            >
                            > Using Visual C++ 2010 in XP and WINVER=0x500, find / replace dialogs
                            > do not work (the commands just fail silently).
                            >
                            > As an alternative, we can load kernel32.dll and bind the memory
                            > address of MemoryStatusEx. If it isn't found, then fallback to
                            > MemoryStatus, thus eliminating the requirement of changing WINVER.

                            Setting WINVER to 0x0500 is needed at compile time. The idea was to set
                            the default in Make_ming.mak and Make_cyg.mak, thus Visual C++ is
                            unaffected.

                            --
                            How many light bulbs does it take to change a person?

                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                            \\\ an exciting new programming language -- http://www.Zimbu.org ///
                            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                            --
                            You received this message from the "vim_dev" maillist.
                            Do not top-post! Type your reply below the text you are replying to.
                            For more information, visit http://www.vim.org/maillist.php
                          • Chris Sutcliffe
                            ... I ve built a native Windows gvim using the MinGW and mingw-w64 toolchains under Cygwin using the following commands: MinGW: make -f Make_ming.mak CROSS=yes
                            Message 13 of 15 , Jul 1, 2012
                            • 0 Attachment
                              On 1 July 2012 16:23, Bram Moolenaar wrote:
                              > Charles wrote:
                              >> Using Visual C++ 2010 in XP and WINVER=0x500, find / replace dialogs
                              >> do not work (the commands just fail silently).
                              >>
                              >> As an alternative, we can load kernel32.dll and bind the memory
                              >> address of MemoryStatusEx. If it isn't found, then fallback to
                              >> MemoryStatus, thus eliminating the requirement of changing WINVER.
                              >
                              > Setting WINVER to 0x0500 is needed at compile time. The idea was to set
                              > the default in Make_ming.mak and Make_cyg.mak, thus Visual C++ is
                              > unaffected.

                              I've built a native Windows gvim using the MinGW and mingw-w64
                              toolchains under Cygwin using the following commands:

                              MinGW:
                              make -f Make_ming.mak CROSS=yes CROSS_COMPILE=i686-pc-mingw32- WINVER=0x0500

                              mingw-w64:
                              make -f Make_ming.mak CROSS=yes CROSS_COMPILE=i686-w64-mingw32- WINVER=0x0500

                              in both cases gvim worked as expected (including the find and replace
                              dialogues).

                              So I think setting WINVER to 0x0500 in Make_ming.mak is safe.

                              Cheers,

                              Chris

                              --
                              Chris Sutcliffe
                              http://emergedesktop.org
                              http://www.google.com/profiles/ir0nh34d

                              --
                              You received this message from the "vim_dev" maillist.
                              Do not top-post! Type your reply below the text you are replying to.
                              For more information, visit http://www.vim.org/maillist.php
                            • Charles
                              ... Alternatively, this condition in the patch if (g_PlatformId != VER_PLATFORM_WIN32_NT) can be replaced with if (WINVER
                              Message 14 of 15 , Jul 1, 2012
                              • 0 Attachment
                                On Mon, Jul 2, 2012 at 6:33 AM, Chris Sutcliffe <ir0nh34d@...> wrote:
                                > On 1 July 2012 16:23, Bram Moolenaar wrote:
                                >> Charles wrote:
                                >>> Using Visual C++ 2010 in XP and WINVER=0x500, find / replace dialogs
                                >>> do not work (the commands just fail silently).
                                >>>
                                >>> As an alternative, we can load kernel32.dll and bind the memory
                                >>> address of MemoryStatusEx. If it isn't found, then fallback to
                                >>> MemoryStatus, thus eliminating the requirement of changing WINVER.
                                >>
                                >> Setting WINVER to 0x0500 is needed at compile time. The idea was to set
                                >> the default in Make_ming.mak and Make_cyg.mak, thus Visual C++ is
                                >> unaffected.
                                >
                                > I've built a native Windows gvim using the MinGW and mingw-w64
                                > toolchains under Cygwin using the following commands:
                                >
                                > MinGW:
                                > make -f Make_ming.mak CROSS=yes CROSS_COMPILE=i686-pc-mingw32- WINVER=0x0500
                                >
                                > mingw-w64:
                                > make -f Make_ming.mak CROSS=yes CROSS_COMPILE=i686-w64-mingw32- WINVER=0x0500
                                >
                                > in both cases gvim worked as expected (including the find and replace
                                > dialogues).
                                >
                                > So I think setting WINVER to 0x0500 in Make_ming.mak is safe.

                                Alternatively, this condition in the patch

                                if (g_PlatformId != VER_PLATFORM_WIN32_NT)

                                can be replaced with

                                if (WINVER <= 0x400)

                                which is more correct since NT does not have MemoryStatusEx.

                                By the way, assuming most people do not compile gvim themselves, what
                                WINVER value will
                                be used to compile gvim windows binary distribution?

                                --
                                You received this message from the "vim_dev" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php
                              • Bram Moolenaar
                                ... No, that would replace a runtime check (what system Vim is running on) with a compile time check (where Vim was build). That won t work, because the
                                Message 15 of 15 , Jul 2, 2012
                                • 0 Attachment
                                  Charles wrote:

                                  > On Mon, Jul 2, 2012 at 6:33 AM, Chris Sutcliffe <ir0nh34d@...> wrote:
                                  > > On 1 July 2012 16:23, Bram Moolenaar wrote:
                                  > >> Charles wrote:
                                  > >>> Using Visual C++ 2010 in XP and WINVER=0x500, find / replace dialogs
                                  > >>> do not work (the commands just fail silently).
                                  > >>>
                                  > >>> As an alternative, we can load kernel32.dll and bind the memory
                                  > >>> address of MemoryStatusEx. If it isn't found, then fallback to
                                  > >>> MemoryStatus, thus eliminating the requirement of changing WINVER.
                                  > >>
                                  > >> Setting WINVER to 0x0500 is needed at compile time. The idea was to set
                                  > >> the default in Make_ming.mak and Make_cyg.mak, thus Visual C++ is
                                  > >> unaffected.
                                  > >
                                  > > I've built a native Windows gvim using the MinGW and mingw-w64
                                  > > toolchains under Cygwin using the following commands:
                                  > >
                                  > > MinGW:
                                  > > make -f Make_ming.mak CROSS=yes CROSS_COMPILE=i686-pc-mingw32- WINVER=0x0500
                                  > >
                                  > > mingw-w64:
                                  > > make -f Make_ming.mak CROSS=yes CROSS_COMPILE=i686-w64-mingw32- WINVER=0x0500
                                  > >
                                  > > in both cases gvim worked as expected (including the find and replace
                                  > > dialogues).
                                  > >
                                  > > So I think setting WINVER to 0x0500 in Make_ming.mak is safe.
                                  >
                                  > Alternatively, this condition in the patch
                                  >
                                  > if (g_PlatformId != VER_PLATFORM_WIN32_NT)
                                  >
                                  > can be replaced with
                                  >
                                  > if (WINVER <= 0x400)
                                  >
                                  > which is more correct since NT does not have MemoryStatusEx.
                                  >
                                  > By the way, assuming most people do not compile gvim themselves, what
                                  > WINVER value will
                                  > be used to compile gvim windows binary distribution?

                                  No, that would replace a runtime check (what system Vim is running on)
                                  with a compile time check (where Vim was build). That won't work,
                                  because the availability of the method depends on where you run Vim.

                                  If NT does not have the method, we need to use something else than
                                  g_PlatformId. I don't have any NT system, thus I can't verify. And
                                  even with an NT system we have to be careful about system updates that
                                  might be missing on another system.

                                  --
                                  Where do you want to crash today?

                                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                                  --
                                  You received this message from the "vim_dev" maillist.
                                  Do not top-post! Type your reply below the text you are replying to.
                                  For more information, visit http://www.vim.org/maillist.php
                                Your message has been successfully submitted and would be delivered to recipients shortly.