Problems with VirtualAlloc/Lock

[MIchael Ost]

There are major differences in the handling of virtual memory in Wine vs
WinXP that are causing problems for my winelib application. Can someone
provide background and/or workarounds for these issues?

As near as I can tell the main differences are:
* VirtualLock does nothing in Wine
* Wine makes no distinction between MEM_RESERVE and MEM_COMMIT
* Wine has no implementation of Windows' process working sets
* Wine limits MEM_RESERVE to 1GB, but WinXP goes up to 2GB

The above problems seem relatively harmless on systems with < 1GB RAM.
But when our units go greater than 1GB we are seeing spectacular
crash-and-burn failures. The code-only DLLs we are running on such
systems are crashing at a stage when I suspect they are attempting to
lock RAM. 

I suspect that they are confused by the report from GlobalMemoryStatus
that more than 1GB of RAM is installed, but that they are only able to
VirtualLock up to 1GB. And in this unexpected situation, they are
crashing.

Further, these DLLs are audio processing plugins. The apparent fact that
VirtualLock doesn't _actually_ lock memory into RAM for real time
processing is a disaster for our system, in that it causes audio
glitches when a page fault is handled. But that is not a problem which
crashes the system.

Any suggestions on what to do? Is there any pending work on this area
out there?

I've attached a little table that describes what I found. It shows the
differences in how Wine and WinXP handle memory related calls. I have
also attached a simple program which can be run to see these
differences.

Thanks for any help... mo 

-------------- next part --------------
Memory Function Differences Between Wine and WinXP
All sizes are in Kbytes

CALL									WINXP 			WINE
=================================================================
1. VirtualAlloc(MEM_RESERVE)			2,096,912		1,020,976
2. VirtualAlloc(MEM_COMMIT)				1,011,712 (3)	1,020,976
3. VirtualAlloc(MEM_COMMIT)			    	1,024 (1)	1,020,976
	+VirtualLock()
4. VirtualAlloc(MEM_COMMIT)				  259,072		1,020,976 (2)
	+SetProcessWorkingSetSize(260,000)
	+VirtualLock()
5. GlobalMemoryStatus
	RAM 								  392,688		  386,324
	Page								  942,820		  522,072
	Virtual 							2,097,024		2,097,024
6. GetProcessWorkingSetSize() hi/lo	    1,380/200		32,768/32,768 (2)

tests:
	1. calling VirtualAlloc with MEM_RESERVE 1MB at a time until it fails. This
	is reserving virtual space only. Without the /3GB switch windows memory is
	limited to 2GB. So each app should be able to reserve its 2GB of space.
	call: drink-memory.exe.so -reserve-only -no-lock

	2. VirtualAlloc(MEM_COMMIT) 1MB at at time until it fails.  On WinXP this
	seems to be bounded by how big the paging file is. In Wine...? dunno.
	call: drink-memory.exe.so -no-lock

	3. VirtualAlloc(MEM_COMMIT) + VirtualLock() 1MB at at time until it fails.  
	On WinXP this craps out right away because the working set is very small,
	1.3M (see line 6)
	call: drink-memory.exe.so
	
	4. Same as 2. but with SetProcessWorkingSetSize(260,000). That was the
	largest value WinXP allowed me to set the working set size to. WinXP
	let me lock down RAM up to its limit, as expected. Wine, again, isn't
	doing anything special
	call: drink-memory.exe.so -lock-limit=260000

	5. & 6. For reference the memory status reported WinXP and Wine
	
notes:
	(1) VirtualLock fails - 1453 Insufficient quota
	(2) FIXME: stub
	(3) VirtualAlloc fails - 1455 Paging file is too small
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drink-memory.cpp
Type: text/x-c++
Size: 3520 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050314/f8beb770/drink-memory.bin