This reverts commit 5c8ea25014f ("ntdll: Use CLOCK_REALTIME_COARSE for
NtQuerySystemTime() if it has sufficient resolution.")
CLOCK_*_COARSE only provides up to 1ms resolution at CONFIG_HZ=1000.
OTOH, there are several ways to get up to 0.5ms resolution on modern
Windows (high resolution waitable timers, NtSetTimerResolution with
0.5ms). This code path therefore has a possibility of behaving worse
than native.
Since COARSE resolution is HZ dependent, this code path only runs if the
kernel is configured with CONFIG_HZ=1000. Most distro ships does not
ship with this. Therefore, this code path is rarely tested, and is more
of a recipe for surprise. If any application rely on fast
NtQuerySystemTime they are likely already broken for majority of Wine
users.
Given the above reason, don't use CLOCK_REALTIME_COARSE. Use
gettimeofday which is internally hooked to CLOCK_REALTIME.
--
v3: ntdll: Don't use CLOCK_REALTIME_COARSE
https://gitlab.winehq.org/wine/wine/-/merge_requests/6007
Apologies for it spamming the log. My intention was, as my comment describes, to be louder about cases where we're running out of memory. Often such allocation failures are indeed fatal, since many applications (and internal Wine code) does not expect them. I didn't intend for there to be, nor did I write, any requirements around the bits of address space. It raises the question for me of why we're trying to allocate memory that high if we know it's above the address limit.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3598#note_75958