Heather's gotta work with XP (and maybe Win98)...  too many people (including me) run it on old trashy laptops, so no fancy pants new fangled Windoze calls allowed...

In the past I've avoided the use of QueryPerformanceCounter due to potential issues with AMD processors, multi-core processors and multi-processor systems,  inaccurate/invalid reported CPU clock frequency (TSC tick count divisor) values,  variable clock rate systems, etc.  I'm now back to using it, but have added an option for switching back to GetTickCount() and it's 16 msec granularity.  I'm getting very good results so far.

Can't you take care of this in the build system?  I never go near
Windows, the last version I used was Win 95.  But on other systems I
always use something like the GNU Auto tools cmake or whatever and
part of the process is to check for the availability of each system
call and library and then the source is built using what's on that
specific machine.  I'd guess that there is something like this in
Windows.  Is GNU Autoconf ported to Windows?  If so then use
QueryPerformanceCounter() if it is available.  It seems much cleaner
to that care of this kind off thing in the build process

On Sun, Jul 17, 2016 at 2:23 PM, Mark Sims holrum@hotmail.com wrote:

--

Chris Albertson
Redondo Beach, California

From: Mark Sims

Heather's gotta work with XP (and maybe Win98)...  too many people
(including me) run it on old trashy laptops, so no fancy pants new fangled
Windoze calls allowed...

In the past I've avoided the use of QueryPerformanceCounter due to potential
issues with AMD processors, multi-core processors and multi-processor
systems,  inaccurate/invalid reported CPU clock frequency (TSC tick count
divisor) values,  variable clock rate systems, etc.  I'm now back to using
it, but have added an option for switching back to GetTickCount() and it's
16 msec granularity.  I'm getting very good results so far.

Mark,

You can easily use the new functions if they are available simply by asking
Kernel32.dll whether it knows about them.  If not, use the old function, if
so, use the new.  The result from old and new is identical in format, just
better in precision in the newer.

---=
var
FPreciseFT: procedure (var lpSystemTimeAsFileTime: TFileTime); stdcall;

begin
FKernel32 := LoadLibrary ('kernel32.dll');
if FKernel32 <> 0 then
begin
FPreciseFT := GetProcAddress (FKernel32,
'GetSystemTimePreciseAsFileTime');
if @FPreciseFT = nil then
FPreciseFT := GetProcAddress (FKernel32, 'GetSystemTimeAsFileTime');
FreeLibrary (FKernel32);
end;
end.

---=

Cheers,

SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv

Mark, Chris,

Chris Albertson wrote:

The QueryPerformanceCounter() (QPC) call is available on all Windows
Versions since Windows NT. I'm not sure if it was supported on Windows
9x, though. The windows 9x versions were more like DOS with a graphical
user interface.

QPC is implemented in the Windows Hardware Abstraction Layer (HAL). At
least Windows versions around XP were shipped with different versions of
the HAL DLL, and the Windows installer determined during installation
which version to use. The different versions used different timers on
the particular PC, and depending on the timer which was actually used
(TSC, HPET, PMTIMER, ...) the QPC call worked with different clock
frequencies and thus provided different resolution.

When Windows XP was current then current CPU types both from Intel and
AMD had problems with the TSC since the TSC clock frequency could change
when the CPU clock frequency changed due to power savings, and TSCs
might not have been synchronized across different cores in the same
physical CPU.

This is why you could force Windows XP always to use the PMTIMER which
is part of the ACPI support chipset, and if I remember correctly the SP3
for Windows XP did this automatically to avoid problems with the TSC.
You can use the QueryPerformanceFrequency() call to determine the clock
frequency of the timer used for QPC, and the frequency typically tells
you which timer/counter circuit or the PC it actually is.

One important point is that the TSC can be read very much faster than
one of the other timers/counters since its just reading a CPU register,
while other circuits are part of the chip set and need to be accessed
via a peripheral bus.

Modern Windows versions determine much more reliably if the TSC can be
used without problems, or not, and use it, if appropriate.

Modern Windows versions (Windows 8 an newer) also provide some new API
calls which return the system time with higher resolution/precision than
original API calls.

For example, the original API call GetSystemTimeAsFileTime() only had a
coarse resolution of 0.5 to ~ 16 ms, depending on the Windows version
and some conditions. Now there's a new API call
GetSystemTimePreciseAsFileTime() which always provides 100 ns
precision/resolution. Similar with some other call for which there are
"Precise" variant available now.

A common practice is to check at runtime if a "Precise" call is
supported by the OS version under which the application is currently
running.

For example, at program startup try to import the symbol
GetSystemTimePreciseAsFileTime and set up a function pointer with it. If
the symbol can't be imported (e.g. if running on windows XP) set the
pointer to GetSystemTimeAsFileTime, and get system time stamps only by
calls via that pointer. So you have a single executable which benefits
from the "Precise" call if available, and falls back to the standard
call if it's not available.

This page
https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408%28v=vs.85%29.aspx

provides a good overview of the available functions.

Martin