@ Thrull:
You don't have to "believe" me, you just need to read the Timers API:
The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
http://msdn.microsoft.com/en-us/library/ms644902%28VS.85%29.aspx
This means things like keyboard events, mouse events and probably many others can all make a timer run slow.
And yes, /timer *is* implemented via WM_TIMER.
But more pertinent: timers
do function the same on all versions of windows. The problem here is that your expectation is not reasonable. /timer is neither expected to trigger in order (-d triggers them in order on mIRC's end, not Windows') nor give you "exact" timings. It's well known that a "1 second" timer will never trigger in exactly 1000ms. In fact, the actual timing could be anywhere from 500ms to 1500ms, given "bug reports" of the past (they weren't actually bugs, of course). With this fact in mind, it's conceivable that 3 timers could easily trigger out of order (timer1 triggers in 1500ms but the others trigger in ~900ms). This is how the Windows API works, and pretty much how any sort of multi-threaded environment (or emulation thereof) will be expected to function. In fact, even the Windows API docs tell you that pretty much nothing is accurate to 1ms by default (it's more like 15ms). That means that if you need to do time-sensitive work, you need to tell the OS; this is what -h is for. Otherwise your timers are approximations and should
not be time sensitive.
The fact that on Win7 the numbers order up is irrelevant. You should not be
expecting any order without -h.
