Alexandre Julliard wrote:
You can probably fix it by passing PM_NOYIELD in the PeekMessage calls. But if your app needs a lot of CPU, restructuring the code to avoid all the needless polling would give much better results, and probably improve the behavior on Windows too.
That's just a workaround. Our PeekMessage is definitly misbehaving - I ran the attached test-program in Wine and WinXP... here are the results:
Wine:
wine@majestix c $ wine foo.exe NtYieldExecution yielded 100 times PeekMessage(...) yielded 200 times PeekMessage(... PM_NOYIELD) yielded 100 times
WinXP: C:>foo.exe NtYieldExecution yielded 100 times PeekMessage(...) yielded 0 times PeekMessage(... PM_NOYIELD) yielded 0 times
(The numbers slightly differ between runs for obvious reasons but they are close enough (with an error margin of +/- 10 we could maybe make this a real testcase))
So, PeekMessage always yields execution (it shouldn't) with PM_NOYIELD specified it yields execution twice (although it shouldn't at all).
The (real) effect of PM_NOYIELD is described at http://www.piclist.com/techref/os/win/api/win32/func/src/f67_6.htm
You can optionally combine the value PM_NOYIELD with either PM_NOREMOVE or PM_REMOVE. However, PM_NOYIELD has no effect on 32-bit Windows applications. It is defined in Win32 solely to provide compatibility with applications written for previous versions of Windows, where it was used to prevent the current task from halting and yielding system resources to another task. 32-bit Windows applications always run simultaneously.
Felix