I don't know the answer to those questions, but in checking its
senders in my image, I did notice a couple by RFB-Server, which is a
pretty important external package.  Whatever answer is arrived at
would be nice if it involves keeping RFB in a functioning state for
the community (and hopefully eventually included in the base image).

Best,
  Chris

On Fri, Sep 11, 2020 at 4:54 PM David T. Lewis <lewis at mail.msen.com> wrote:
>
> 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
>
>
>