[Bug 10343] SetTimer won't wait for specified time

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Nov 13 03:28:15 CST 2007


http://bugs.winehq.org/show_bug.cgi?id=10343


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net




--- Comment #9 from Anastasius Focht <focht at gmx.net>  2007-11-13 03:28:14 ---
Hello,

--- quote ---
"integer" the UINT_PTR type is 64-bit unsigned int. Which can have _ANY_ value,
including 1.
--- quote ---

For the "joe average" programmer who doesn't question anything written this
statement might be the true but we all know from the technical standpoint
[under the hood] MSDN this isn't always right.
Having worked many years with the win32 API/kernel i've encountered countless
bugs/quirks documented and undocumented that I hardly believe in anything
written because it says "MSDN".
Back to topic ;-)

It is true that windows reserves a specific range from which it allocates timer
 id's for newly created timer objects.
Usually between 0x3E8 (min timer id) and 0x7FFF (max timer id).
Though numbers might slightly differ, depending on windows version.

The important fact is: timer id's are allocated backwards, starting from "max
timer id" until "min timer id" is reached. It then wraps around to max again.
If the timer id space is exhausted, creation of new timers is denied.

Proof?
Write a simple loop which repeatedly calls SetTimer() and keeps track of
returned timer id's.

In my opinion wine should at least mimick the "backwards allocate timer id's
from max. value" of windows.
Wine's timer id allocation scheme might trigger side effects in broken windows
apps.

Regards


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list