> On 27-04-2018, at 1:52 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> Of course there has to be a generic representation to account for OS specifics.

Actually there really doesn't (well, unless we count "there's this stuff in memory") need to be any abstraction within the *VM* layer. There doesn't even have to be a primitive to get the event data, not in the sense of primitiveFetchAbstractedEventDataAsMyKindOfArray.

It is quite possible to make an ffi call (or maybe using Alien would be smarter) to fetch the OS event data and then process it entirely in the image. Yes, there may be a number of other ffi calls to pass some of it back to the OS for certain things. Yes, some OS's do very strange stuff. Actually, strike that - every bit of stuff I can remember about handling these things is a litany of ridiculous coding.

There is/was an existence proof in the ancient 'Van Gogh' project from mid-90's ParcPlace. There were plenty of problems - especially back then Windows was ... deranged about this stuff. NT was actually quite reasonable IIRC (which given it is nearly 25 years ago may be a poor bet) and Mac OS wasn't too bad. OS/2 was in the picture as well, and I think that was seen as quite nice for this purpose. Even though I had a sorta-working RISC OS HPS back then it wasn't included in the project :-(

The abstraction can be much higher than the untouchable VM if you want it to be.


> It's a trade off. There is always a compromise. We extract meaningful data, put it in an array and let the Squeak image handle the object representation for it.

Yes, trade-offs are where we have to look most of the time. The current arrangement has the advantage that you can (in theory and in most cases, in reality) make your new vm and process OS events in the VM and pass the array up and an image will (mostly) work on your new machine. That's good and has been very valuable. A downside is that any new OS event stuff will almost certainly require new VMs, whereas the 'Van Gogh' model would be fixable with a simple image update.

It's a similar picture to much other OS interface. We currently have an ancient and somewhat creaky file interface with an assortment of added stuff that could all do with cleaning. It relies on a very narrow interface through the ANSI/Posix C lib, which was ok for initial creating of the platforms vms but isn't all that well suited to anything. We could perfectly reasonably create more platform supportive filing system access with ffi/alien calls. Again, an existence proof stems from ancient work, in this case by (mostly)Eliot & I back in the late 1980s when we had an ffi-equivalent based file interface for RISC OS that used raw OS SWI calls and meant that Eliot was able to write image level code that allowed us to read DOS discs on a machine that had a wildly different native disc data format.

All we need is a boat-load of money to support changing everything.....

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Out there where the buses don't run.