[PATCH 1/2] kernel32: Implement GetSystemTimePreciseAsFileTime

[Martin Storsjö]

On Tue, 12 May 2015, Martin Storsjö wrote:

> On Tue, 12 May 2015, Andrew Eikum wrote:
>
>> On Thu, May 07, 2015 at 11:02:34PM +0300, Martin Storsjo wrote:
>>> +/***********************************************************************
>>> + *              GetSystemTimePreciseAsFileTime  (KERNEL32.@)
>>> + *
>>> + *  Get the current time in utc format, with <1 us precision.
>>> + *
>>> + *  RETURNS
>>> + *   Nothing.
>>> + */
>>> +VOID WINAPI GetSystemTimePreciseAsFileTime(
>>> +    LPFILETIME time) /* [out] Destination for the current utc time */
>>> +{
>>> +    GetSystemTimeAsFileTime(time);
>>> +}
>> 
>> I don't know why this one's not getting in. I have a couple small
>> guesses.
>> 
>> Personally, I'm opposed to including a bunch of documentation in Wine.
>> I don't think Wine is the right place to document the Windows API. I
>> don't know if others feel this way, or if this is enough for
>> rejection.
>> 
>> You're also using VOID, LPJUNK, etc, which I think we're trying to
>> avoid these days.
>
> Ok, thanks. In this case, it's pretty much a copypaste of the existing 
> GetSystemTimeAsFileTime() function, with the body swapped out, and with the 
> function comment extended (because to me it's quite puzzling why there's two 
> separate functions).

Alexandre wanted to have tests for this; I did some testing on Windows 8 
(running in a VM). With GetSystemTimeAsFileTime(), the minimum increment I 
get on the returned values is about 15.6 ms, while for 
GetSystemTimePreciseAsFileTime(), I get increments at around 0.3 us, 
possibly even less.

With wine, I get 1 us increments for the existing GetSystemTimeAsFileTime. 
(According to the docs for GetSystemTimePreciseAsFileTime, it should have 
precision < 1 us, but exactly 1 us is probably close enough as well.)

Is there any reason to artifically limit the precision of the current 
function? And does it make sense to have a test that busyloops calling 
both of the functions, finding out the minimum increment of each of the 
functions? By having it run for a couple hundred milliseconds it should 
probably be enough to get useful data, but this still would be a kinda 
brittle test, susceptible to scheduler interruptions.

// Martin