For some purposes it can be highly desirable to use GetSystemTimePreciseAsFileTime() whenever it is available (i.e. Win8+) because the accuracy of GetSystemTimeAsFileTime() isn't very high and it varies from system to system. On old systems it's tied to the 15.625 ms heartbeat, but even the 1 ms of newer systems is a small eternity for a multi-core system clocked at several GHz. The full story can be read at Arno Lentfer's amazing site Microsecond Resolution Time Services for Windows and in the MSDN article Acquiring high-resolution time stamps which is also of unusually high quality.
In order to reduce hassle, the initialisation logic with GetProcAddress() etc. should be automatic and thread-safe, fully transparent to the caller. The final code will be added to a general Win32 utility unit (hence the prefix zw_) but for this post I've broken it out as a separate unit.
Exporting a wrapper function instead of the naked function pointer adds a bit of call overhead but that should be negligible compared to the expense of the wrapped system call. Conversely, lifting the function pointer into the interface would make the code cleaner and meaner but it would pollute the global namespace with the symbols necessary for declaring and initialising the function pointer.
Overall the wrapper function approach seems preferable since it makes the global/external situation as clean and mean as is possible at all (with the target function being the only globally visible name), and the increase in local complexity is quite manageable/affordable. The same reasoning applies to having the linker initialise the function pointer instead of resorting to the flaky practice of using the unit's initalization section for the purpose. Also, I find it preferable to see a variable initialised statically right there and then instead of having to jump to the initialization in order to verify that the variable does indeed get initialised appropriately (or to find out what it gets initialised with).
The declaration of the wrapper function was chosen to make it 1:1 compatible with the GetSystemTimeAsFileTime function found in the Windows unit shipped by Borland/Embarcadero, with all its b0rkedness. It's amazing how they managed to get the declaration of the majority of the Windows API wrong, but like it or not, it's what we have to work with and sticking with it helps to reduce confusion.
The $ifdef VER150 stuff will be replaced with appropriate prepro symbols but at the moment my compiler adaptation include file is more than ten years old. It's woefully out of date and needs a serious overhaul.
I've put a small test program on PasteBin, where the meat of the test looks like this:
There's a second function exactly like this, but with zw_GetSystemTimeAsFileTime substituted for GetSystemTimeAsFileTime.
Output for Delphi 7 under WinXP/32 (XPMode run in a VMWare VM); the first row of measurements is for GetSystemTimeAsFileTime(), the second is for the zw_ variant:
The overhead for the wrapper and the indirect function call is clearly visible but it seems quite unproblematic, all things considered.
Output for the same binary under Win81/64:
It's easy to see the update interval for the standard function of 10.0144 ms under WinXP vs. roughly 1 ms under Win81. It's also easy to see how the zw_ autoinit picks up the more precise function under Win81, which results in a resolution of 300 to 400 ns.