GetTickCount lies??

[Git]

I see your point overflow, but thinking about it, couldn't the GetTickCount() function get robbed of CPU time and hence run slow?. All depends how it is implemented. If it reads a real time clock, or is interrupt driven then it should never return a low count. If it is just a queued task bumping a counter I think it could. In this example, the same applies to the Sleep() function.

Git

[gigaman]

You cannot rely on any exact timing on Windows - it's not a real-time OS.
A context switch may always occur in the middle of your code, delaying it significantly. For example, you call the first GetTickCount, then Sleep - and after the Sleep function returns (and before the second GetTickCount is called), your process loses the CPU, another running process uses it for a while (say 20ms to the next timeslice), and then you get it back - so it looks like your Sleep actually took 20ms longer.
[OK, I know this scenario is quite unlikely with this particular code, because you'd probably get a full timeslice after Sleep, but it's just to illustrate the point].

As for why it should be less than 1000 ms... even the today's hardware doesn't make it easy for exact timing. With all those turbo modes (the CPU frequency gets temporarily increased under load) and power saving features (the CPU clock is reduced if not under heavy load - especially on mobile devices), it's very hard to measure time exactly.

VirtualDub's author wrote about it years ago: http://virtualdub.org/blog/pivot/entry.php?id=106

[Squidge]

It could also be that the resolution of the system clock isn't that accurate.

Did you try using timeBeginPeriod to set the timer resolution ?

Don't forget that Sleep works by creating a thread to release the remainder of your time slice, which also involves delays.