Re: [PATCH 1/2] kernel32: Implement GetSystemTimePreciseAsFileTime
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. Andrew
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). Since different parts of the codebase use different conventions, I've tried to match the surrounding style unless otherwise suggested. // Martin
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
Martin Storsjö <martin(a)martin.st> writes:
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.
We don't care about the exact precision, so it would be enough to test that both functions always return the same data within 100ms or so, and that GetSystemTimePreciseAsFileTime result changes within 1ms or so. -- Alexandre Julliard julliard(a)winehq.org
participants (3)
-
Alexandre Julliard -
Andrew Eikum -
Martin Storsjö