test case demonstrating PeekMessage give up timeslices

Felix Nawothnig felix.nawothnig at t-online.de
Tue Aug 2 10:51:16 CDT 2005

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 at majestix c $ wine foo.exe
     NtYieldExecution yielded 100 times
     PeekMessage(...) yielded 200 times
     PeekMessage(... PM_NOYIELD) yielded 100 times

     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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.c
Type: text/x-csrc
Size: 1191 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050802/eff9eaf1/foo.c

More information about the wine-devel mailing list