All timers should either be really tiny (whereupon they are good subjects for test cases) or really huge and not subject to possible rollover (64 bits of nanoseconds is 580 years, and should serve for an interval counter).
128 bits of nanoseconds is 10E22 years, and should serve to drive calendar time, unless you're doing cosmology.
The API call in question is called GetTickCount[1], and it's still really popular - especially for doing quick things like comparing for timeouts, and so forth. It returns milliseconds into a 32-bit int.
There's a replacement named, funnily enough, GetTickCount64, but iirc it's only present on Vista and newer, so it hasn't found its way into a lot of software yet. The Windows Performance counters probably provide better metrics for people actually interested in this data.
I recently had to implement a version of GetTickCount64 for older platforms that only support GetTickCount(32). It works great as long as you remember to call it at least every 49.7 days. :-)
(Luckily the process already had a thread which wakes up to perform such maintenance every hour or so.)
All timers should either be really tiny (whereupon they are good subjects for test cases) or really huge and not subject to possible rollover (64 bits of nanoseconds is 580 years, and should serve for an interval counter).
128 bits of nanoseconds is 10E22 years, and should serve to drive calendar time, unless you're doing cosmology.