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

Re: Patch 7.3.582

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.