http://bugs.winehq.org/show_bug.cgi?id=10343
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #9 from Anastasius Focht focht@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