Hi,   This version of GetTickCount works in both flavors (32Bit and 64Bit) on all 64Bit Windows versions, the result is identical to both APIs, also the 32Bit version of it will work on all 32bit Windows versions, the problem is i don't have access to to 32Bit Windows that is running for more than 49.7 days to test the 64Bit result version,    And here comes the question for the help, if anyone have access to such OS, like Windows XP or Server 2003 that is running for that long time, it will be great help to test the result from the 64Bit result form this emulated API, and confirm it does return true value with value above the 32Bit. function GetTickCount64Emu: UInt64; const KUSER_BASE_ADDRESS = $7FFE0000; //KUSER_BASE_ADDRESS_KERNEL_MODE =$FFFFF78000000000; //in case it is needed begin Result := (PUInt64(KUSER_BASE_ADDRESS + $320)^ * PCardinal(KUSER_BASE_ADDRESS + $4)^) shr 24; end; Rename as you wish, and adjust as you see fit, like make the result Cardinal to replace GetTickCount or keep it as UInt64, it doesn't matter.   and keep in mind it does exactly what GetTickCount and GetTickCount64 do, as this snippet i decompiled form the OS, also this address is fixed across Windows versions, and belongs to a readonly page protected, also in the past, well, far past Microsoft documentation for DDK, was suggesting using the same algorithm for games engines to ditch calling API for timing, to squeeze few extra cycles, so even if this approach is not documented now, it was and will stay accessible. The operation of multiplication and shifting is as it seems a simple division, but with fixed point, hence the bit shifting, per Microsoft documentation the Windows OS kernel is prohibited from using float point operation, and only fixed point are allowed, those has the point at 24th bit.   If someone has insight about this, then please share, and if someone can confirm a result over 32bit on an old or new 32Bit system that was and is running for over 49.7 days, then it will be great to share the result.