windows: resync the VM time when the system clock gets changed

[LinqLover]

As of today, if the Windows system time is changed, already running VM instances will not reflect this change. With this patch, this bug is fixed. The full bug report is on squeak-dev: https://lists.squeakfoundation.org/pipermail/squeak-dev/2021-August/216306.html

This bug only affects builds for Windows versions prior to Windows 8, never builds do not use the tick variables any longer. See:

opensmalltalk-vm/platforms/win32/vm/sqWin32Heartbeat.c

Lines 79 to 85 in 57260c2

	#if (_WIN32_WINNT >= _WIN32_WINNT_WIN8)
	/* Compute the current VM time basis, the number of microseconds from 1901.
	*
	* As of Windows 8 there is a FILETIME wall clock interface which is high
	* precision and so does not have to be combined with the millisecond clock.
	*/

(However, as #499 is still unmerged, currently, also builds for Windows 10 are affected by the bug. Looks like we were never benefitting from @eliotmiranda's improvements for the Win8 APIs (cf. fae0d31) until today 😆)

Independently of this patch, we will want to fix cross-platform-occurring VM hangs when the system clock is pulled backward. See the bug report on squeak-dev for this, again.

Please review thoroughly!

/cc @marceltaeumel

[LinqLover]

(By the way, the best thing while you are dealing with timing issues is that after you have committed all your stuff, you set your system time back to normal and realize that you have spent one hour less on this issue than you were assuming ... ^^)

[marceltaeumel]

FYI: We wanted to bump the minimal supported version to Windows Vista. Eliot suggested even Windows 8 but we still have a lot of Windows 7 users out there. See PR #499

[LinqLover]

Why don't we create multiple builds for the different Windows versions?

[eliotmiranda]

Hi Christoph, hi all,

On Aug 31, 2021, at 1:53 AM, Christoph Thiede ***@***.***> wrote:  Why don't we create multiple builds for the different Windows versions?

That would probably cause disruption to naming schemes etc. an easier way would be to change the code so that - if compiled on a system older than Windows 8 the old ticket variable code is used - if compiled on Windows 8 or later then - at startup the Windows is version is cached in a variable and, - depending on the variable either the new or the old code is evaluated So we keep a single build, and a single version of the code base. Normal builds remain backward compatible. One can still compile on an older system and get a functional, albeit more fragile vm. Note that one could also use the get symbol from dll api (LoadSymbol? can’t remember) to so that a vm built on an older version can use the new api when run on later versions but IMO this is wasted effort and unnecessary complexity Finally, one could consider implementing my adaptive approach that ensures a monotonic clock. But the Windows 8 api makes things so simple it’s (arguably) a lot of work for no gain.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[LinqLover]

Thank you for the feedback, Jakob, and for the explanation, Eliot. Is there anything else that keeps us from getting this one merged? :-)