fix: timestamp resolution to microseconds on Windows

[ShawnCZek]

The timestamp resolution was changed to microseconds in #995. However, this has never correctly worked on Windows because SYSTEMTIME, a return value from the underlying call to GetSystemTime(), contains only milliseconds, not microseconds: https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-systemtime.

Instead, GetSystemTimeAsFileTime() can be used as its return value "contains a 64-bit value representing the number of 100-nanosecond intervals". This also helps in reducing two API calls to just one.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.78%. Comparing base (4c47d97) to head (dda6e61).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1039      +/-   ##
==========================================
+ Coverage   83.76%   83.78%   +0.01%     
==========================================
  Files          53       53              
  Lines        5512     5512              
  Branches     1198     1198              
==========================================
+ Hits         4617     4618       +1     
  Misses        781      781              
+ Partials      114      113       -1     

[ShawnCZek]

Actually, on Windows 8 and later, GetSystemTimePreciseAsFileTime() is available, which is even more precise and is encouraged to be used by Microsoft: https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps#guidance-for-acquiring-time-stamps

[supervacuus]

Thanks!

[dacap]

This PR made any binary linked to sentry-native depends on GetSystemTimePreciseAsFileTime()/incompatible with Windows 7 by default (aseprite/aseprite#4691).

I know that probably we should not be compiling with _WIN32_WINNT >= 0x0602 to give support for Windows 7 (which is 0x0601), but actually we're compiling with _WIN32_WINNT=0x0A00 just to use Windows 10 APIs dynamically (known the API structures) and load functions dynamically.

Probably an approach like Microsoft's STL should be used for this:

https://github.com/microsoft/STL/blob/faccf0084ed9b8b58df103358174537233b178c7/stl/src/winapisupp.cpp#L161-L170

Where GetSystemTimePreciseAsFileTime is loaded dynamically if _STL_WIN32_WINNT < _WIN32_WINNT_WIN8 (do we need a SENTRY_WIN32_WINNT?).

At the moment we'll revert this change to continue giving support for Windows 7.

[ShawnCZek]

I guess we would have to do something similar to the following:

sentry-native/src/sentry_sync.c

Lines 38 to 45 in 65bfb62

	pSetThreadDescription func = (pSetThreadDescription)GetProcAddress(
	GetModuleHandleA("kernel32.dll"), "SetThreadDescription");
	if (func) {
	wchar_t *thread_name_wstr = sentry__string_to_wstr(thread_name);
	HRESULT result = SUCCEEDED(func(thread_id, thread_name_wstr)) ? 0 : 1;
	sentry_free(thread_name_wstr);
	return SUCCEEDED(result) ? 0 : 1;
	}

However, what is the stand on supporting operating systems that went EOL 4+ years ago, especially when done non-standardly by changing definitions? For instance, Sentry Native will not work properly for Windows XP using your technique because of instances like this (GetTickCount64 has only been available since Windows Vista):

sentry-native/src/sentry_utils.h

Lines 145 to 152 in 65bfb62

	// Fallback to GetTickCount() on QPC fail
	if (!qpc_frequency.QuadPart) {
	# if _WIN32_WINNT >= 0x0600
	return GetTickCount64();
	# else
	return GetTickCount();
	# endif
	}

Frankly, I am not a maintainer of this library; it is up to the Sentry team how they want to resolve this. But I do hope we are not defaulting to the previous solution as it is inefficient and inaccurate, as discussed here: https://devblogs.microsoft.com/oldnewthing/20131101-00/?p=2763.

Likewise, I wish new systems were not disadvantaged because of supporting old systems that <1% of users use; GetSystemTimePreciseAsFileTime() turned out to be extremely precise in our case.

[dacap]

We are still giving support for Windows Vista and 7 as we still have ~750 users on those platforms. Windows XP support was dropped and probably Vista and 7 will be dropped in a couple of years. But until we can keep working the code on those platforms that will be great.

The MSVC STL library is already doing this job of dynamically loading the function, probably we can just use __crtGetSystemTimePreciseAsFileTime() when compiling with MSVC.