Hi, compiling binaries with the LARGE_ADDRESS_AWARE flag set is not enough to be able to use more than 2GB user space. To behave like WindowsXP booted with the /3GB option, at least the lpMaximumApplicationAddress in GetSystemInfo has to be changed to 0xBFFEFFFF and the virtual user space has to be reserved in mmap_init in mmap.c up to that address.
See Windows memory management:
http://ymei.freeshell.org/gopher/Book/Programming%20Applications%20for%20MS%... http://codeidol.com/other/inside-windows-2000/Memory-Management/Address-Spac...
I am quite sure that my proposed hack is not complete to behave like the /3GB option, but as stated in cpu.c 384 /* FIXME: the two entries below should be computed somehow... */ 385 cachedsi.lpMinimumApplicationAddress = (void *)0x00010000; 386 cachedsi.lpMaximumApplicationAddress = (void *)0x7FFEFFFF;
we should look at this in order to be able to use more than 2GB user space for apps that need it.
Regards Stefan Reimer
"Stefan Reimer" lists@startux.de writes:
compiling binaries with the LARGE_ADDRESS_AWARE flag set is not enough to be able to use more than 2GB user space. To behave like WindowsXP booted with the /3GB option, at least the lpMaximumApplicationAddress in GetSystemInfo has to be changed to 0xBFFEFFFF and the virtual user space has to be reserved in mmap_init in mmap.c up to that address.
The only thing that needs to be changed is the limit reported in GetSystemInfo, everything else is implemented already. Apps built with LARGE_ADDRESS_AWARE always get 3Gb of space on Wine.
"Stefan Reimer" lists@startux.de writes:
compiling binaries with the LARGE_ADDRESS_AWARE flag set is not enough to be able to use more than 2GB user space. To behave like WindowsXP booted with the /3GB option, at least the lpMaximumApplicationAddress in GetSystemInfo has to be changed to 0xBFFEFFFF and the virtual user space has to be reserved in mmap_init in mmap.c up to that address.
The only thing that needs to be changed is the limit reported in GetSystemInfo, everything else is implemented already. Apps built with LARGE_ADDRESS_AWARE always get 3Gb of space on Wine.
-- Alexandre Julliard julliard@winehq.org
I reverted my changes to mmap.c mmap_init back to char *user_space_limit = (char *)0x7ffe0000; but keeping the 0xBFFEFFFF in GetSystemInfo.
Everquest2 crashes after some minutes. I got following errors in log: err:d3d:CreateIndexBufferVBO Failed to initialize the index buffer with error GL_OUT_OF_MEMORY (0x505) ... and about 100000 of err:syslevel:_EnterSysLevel (0x7ecf9ea0, level 2): Holding 0x7ebda060, level 3. Expect deadlock! before crashing.
Using char *user_space_limit = (char *)0xbffe0000; Everquest2 runs rock stable and uses up to 2.8GB...
So there seems to be an issue either in Everquest2 handling memory or in wine if it comes to using more than 2GB and OpenGL for example.
Any idea how to go from here ? Stefan
"Stefan Reimer" lists@startux.de writes:
I reverted my changes to mmap.c mmap_init back to char *user_space_limit = (char *)0x7ffe0000; but keeping the 0xBFFEFFFF in GetSystemInfo.
Everquest2 crashes after some minutes. I got following errors in log: err:d3d:CreateIndexBufferVBO Failed to initialize the index buffer with error GL_OUT_OF_MEMORY (0x505) ... and about 100000 of err:syslevel:_EnterSysLevel (0x7ecf9ea0, level 2): Holding 0x7ebda060, level 3. Expect deadlock! before crashing.
Using char *user_space_limit = (char *)0xbffe0000; Everquest2 runs rock stable and uses up to 2.8GB...
So there seems to be an issue either in Everquest2 handling memory or in wine if it comes to using more than 2GB and OpenGL for example.
That's a different issue, OpenGL memory isn't allocated through the Wine allocation functions. By changing the limit in mmap.c you disable the memory reservation, which leaves more space for OpenGL, but that's not a general solution.
-
Alexandre Julliard -
Stefan Reimer