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
--------------------
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 <hept...@gmail.com> http://christianrobinson.name/
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.
> 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:
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:
> 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
>> 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.
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 <hept...@gmail.com> http://christianrobinson.name/
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 <hept...@gmail.com> http://christianrobinson.name/
This is quite odd, as I can can compile latest trunk fine without having to change WINVER or _WIN32_WINNT.
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
On Sat, Jun 30, 2012 at 9:22 PM, Bram Moolenaar <B...@moolenaar.net> 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:
>> 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.
Charles wrote:
> On Sat, Jun 30, 2012 at 9:22 PM, Bram Moolenaar <B...@moolenaar.net> 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:
> >> 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?
> 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.
On Mon, Jul 2, 2012 at 6:33 AM, Chris Sutcliffe <ir0nh...@gmail.com> 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?
Charles wrote:
> On Mon, Jul 2, 2012 at 6:33 AM, Chris Sutcliffe <ir0nh...@gmail.com> 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:
> > 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.
