Patch 7.3.582

[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


*** ../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 -- Br...@Moolenaar.net -- 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 ///

[Cesar Romani]

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

[Christian J. Robinson]

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 <hep...@gmail.com> http://christianrobinson.name/

[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 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.

[Chris Sutcliffe]

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

[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 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

[Chris Sutcliffe]

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.

[Christian J. Robinson]

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

[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:
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

[Bram Moolenaar]

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

[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 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.

[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.

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

[Chris Sutcliffe]

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,

[Charles]

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?

[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 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?