Christoph has fixed a bug in event timestamps on the Windows VM. Background
is at https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/518.

This led us to a question about Time>>eventMillisecondClock. To summarize:

Events are delivered to the image by the VM, and processed in the image
as e.g. MorphicEvent. Each event has a timeStamp that is an integer number
of milliseconds since some arbitrary starting point. The actual time basis
(starting point) of those timestamps is not important, just as long as they
are consistent.

In the Windows VM, the event timeStamps are derived from the Windows event
system, and are in milliseconds relative to the time that the Windows system
was started. Other VMs obtain their event time stamps differently, but
normally through ioMSecs() in the VM.

Thus, for any VM, the events must have internally consistent time stamps,
but the timestamps may or may not be aligned with ioMSecs() in the VM.

All good so far, but then Christoph pointed out this in the image:

Time>>eventMillisecondClock
	"In order to make certain event handling code work (cf MouseEvent>asMouseMove) we need access
	to the tick kept by ioMSecs() "
	"Time eventMillisecondClock"
	<primitive: 135>
	^0

This is being used in multiple places in the image, and it explicitly
assumes that event timestamps are relative to ioMSecs() in the VM which
is not the case on Windows.

This leads me to ask three questions:

1) Does #eventMillisecondClock need to exist? It looks like it might be
a kludge, if so could we make it go away?

2) If the eventMillisecondClock method does need to exist, should it be changed
to retrieve a millisecond value that is aligned with that of the events?

3) If not 2) then do we need to change the Windows VM to somehow use event
timestamps that match eventMillisecondClock?

Dave