The behavior is similar to GetTickCount_() and timeGetTime_() but with higher precision, and falls between those and QueryPerformanceCounter_()īut as you see, other than the procedure itself, no system calls are used at all, the interrupt time is read directly from KUSER_SHARED_DATA memory which resides at $7FFE0000 and is exposed in the addressable memory of all processes. (and even if it does, as long as you use the good old 'stop-start' to get your delta value like you'd usually do, even that is not an issue)įor reference 10000 = 1ms. Since it's a 64bit value, despite being 1/10000th of a ms, it'll still take around 58454 years before it wraps around to 0 again, nobody have yet to reach a system uptime of that long. timeBeginPeriod_() affect the resolution of the system clock and timer ticks. On NT the max value (lowest reslution) is around 15.6ms, the min value (highest resolution) is 0.976ms. So on my system the example below returns 156000 (15.6ms) and 156001, and if I un-comment the timeBeginPeriod and timeEndPeriod lines the timer/interrupt resolution increases and I get 10000 (1ms) and 10001. The interrupt time is the base clock for all timers in Windows (see my recent article A Bug in Windows Timer Management). Its value represents the time in units of 100 ns since the system was booted. The interrupt time is the only Windows clock that guarantees to be monotonous that is, its value only increases over timer.

Purebasic 4 51 win x86 portable.exe