Re: What would you want in GS/OS 7.0?

[IUnknown <stevementzer@gmail.com>]

> - Rewrite all the tool sets so that they are safe to use in a preemptive
>    multitasking environment.
> - Add preemptive multitasking capability.

(disclaimer: didn't get much sleep last night- ramblings of a madman)

Sadly, this is one of those things that will likely never be possible,
at least not without requiring additional hardware.

The IIgs GS/OS toolbox shared much of it's architecture with the early
versions of macOS. Even with a proper MMU, apple was never able to get
a reliable version of it working on a mac.

The IIgs is complicated because there is no memory protection in
place, which means that all toolbox calls need to ensure that the
descriptor handles and memory they are working with isn't being used
by someone else... which would require each toolbox call to be
prefixed by some overriding process identifier handle....

Ultimately, rewriting the toolbox is a neat idea, but since the
original interfaces need to retain binary compatibility (stack
signatures cannot change), a massive 'thunking layer' would need to be
established. The nice thing is that the vast majority of toolbox calls
operated using descriptor handles, which was good design from the
outset.

So, a call like (stupid example, not correct in any way shape or form)
    getGrafPort(&handle)
.. would need to internally make a call to
    thunkedGetGrafPort(getCurrentProcessHandle(), &handle)

.. which at that point, the 'preemption manager' would then validate
the use of that handle/resource against the process identifier
specified....

The system would still be vulnerable to use of resources not managed
by the gs/os toolbox, which is an entirely different challenge.

Then there is the issue of stack/state management when switching
between processes.....    With a 2.7mhz main processor, the overhead
of switching the stack and register state (including hardware state
like video modes, etc) would be substantial.

Now, in theory... if you could have a simple slot 2 card that
implemented some of this logic/state management in a coprocessor
(fpga) or something akin to that, it may be viable...   but the key is
being able to trigger the hardware to perform context switches.

Even as a proof of concept, you would need a bare minimum of an
external hardware interrupt generator .....

I don't know A2GS hardware very well, so I assume the slots/bus allow
for hardware interrupts.