Note: if the grab of the current tick count since boot is being done via .NET API the longest I know of to attain would be 24.9 days before a reset ( Using System.Environment.TickCount which uses a 32bit signed integer in Managed C++ ) and 49.7 days before a reset with the Platform SDK ( Using timeGetTime() )
My post about using a double assumed using an ASM call to rdtsc which grabs a 64bit value of the cycles since system boot and saves it in EDX:EAX. then grabing that value and storing it in a double. This would allow for proper tick value of systems with extended uptimes. (seconds = cycles / frequency) This seems well worth it to me, no? :tongue:
* Added API calls per Hammers request.
