Problems with VirtualAlloc/Lock

[Kuba Ober]

> * VirtualLock does nothing in Wine
VirtualLock does nothing in win95,98,ME as well :)

I bet the correct behaviour for wine is to do anything in VirtualLock only if 
you set windows version to NT/2000/XP. Did you do it?

Anyway, mlock() seems to work fine, so this should be implementable.

> * Wine makes no distinction between MEM_RESERVE and MEM_COMMIT
Assuming that we're talking about VirtualAlloc().

It would use mmap():
MAP_PRIVATE must be set. Always.
MEM_RESERVE translates to MAP_NORESERVE (sic!)
MEM_COMMIT translates to nothing, but it should zero the page and methinks 
linux would do it by default (?)
MEM_TOP_DOWN translates maybe to MAP_GROWSDOWN (?)
MEM_WRITE_WATCH can be implemented by mmapping a PROT_READ region, handling 
SEGSIGVs and then mprotect()ing it back to PROT_READ | PROT_WRITE

It would also use madvise():
MEM_RESET translates to MADV_DONTNEED

I wonder to what extent Wine really does any of that. Too busy to take a look 
at the actual code.

> * Wine has no implementation of Windows' process working sets
Linux doesn't either. At least I don't know of a documented API that could 
reliably implement semantics of Windows working sets. Maybe it could be 
implemented on other OSes like some BSDs if they have such APIs. Maybe 
there's something in /proc/sys/vm or somesuch to tweak those, but then it 
would probably be system-wide. I'm no expert here I'm afraid :(

> * Wine limits MEM_RESERVE to 1GB, but WinXP goes up to 2GB
Wine? Maybe linux, but I doubt wine would do anything like that.

> Further, these DLLs are audio processing plugins. The apparent fact that
> VirtualLock doesn't _actually_ lock memory into RAM for real time
I didn't look into the code, but anyway a prerequisite for it would be to set 
windows version to NT/2000/XP. Or at least wine should behave like that, 
assuming that MSDN doesn't lie here.

Apart from that, I bet you didn't raise ulimits for your processes. On my FC3 
system, ulimit -l gives a meager 32 pages. So that's how many mlock() could 
lock anyway.

So, in order for VirtualLock to be able to potentially screw up your 
rock-stable linux system, you have to let it first :)

Cheers, Kuba