Re: Idea: Multitasking graphical OS for the GS

[Eric Rucker <bhtooefr@gmail.com>]

On Jan 3, 12:52 am, David Schmenk <dschm...@sbcglobal.net> wrote:
> Eric Rucker wrote:
> > I've been thinking about stuff, and got to thinking... it'd be
> > interesting if there were a semi-modern, multitasking, graphical OS
> > for the IIGS - not necessarily backwards compatible with GS/OS. (The
> > semi-modern bit means... The Manager on GS/OS does NOT qualify. ;))
>
> > Anyway, I'm thinking that starting from scratch with the OS might just
> > be the best bet - unlike GNO/ME, which uses GS/OS for a lot of stuff.
>
> > That doesn't mean that I'd be shunning all of the built-in IIGS stuff
> > - the Toolbox would come in handy for the GUI. (FWIW, I think I know
> > how I'd handle the toolbox in a multitasking environment - simply
> > create a "virtual toolbox" that apps for this OS would make calls to,
> > and then pass those calls onto the real toolbox. As far as the real
> > toolbox is concerned, it's just one app with a bunch of windows, that
> > wants to change its menus. A lot. ;))
>
> > But, I suspect a modern multitasking kernel for all of this would be
> > more efficient. I know, there's no MMU. That never stopped Minix or
> > ELKS...
>
> > Speaking of Minix, I'm almost wondering if some heavily-modified Minix
> > derived kernel would do the trick. The stock Minix memory manager can
> > only handle 64k of code and 64k of data per application on a 16-bit
> > CPU (I think that's a word-length restriction,) but maybe that could
> > be fixed? Binary compatibility with Minix would be unnecessary, so...
> > And, IIRC, it has installable file systems, and stuff like that, which
> > would work nicely in the IIGS ecosystem.
>
> > But, Minix is just an idea, and isn't necessarily the best one. It's
> > just something to think about.
>
> > Is anyone interested in such an OS? Either using it, developing it, or
> > developing for it?
>
> Another important piece to consider is the development environment.
> Writing a core multitasking kernel isn't particularly difficult, but
> having tools such as compilers and debuggers is a large part of the
> project - sometimes larger than the kernel itself. If you want to make
> it open source, you'll want to find a tool suite that can be made easily
> available.  Do you want to self-host or do you want to cross-compile?
> Determination of the tools might even help dictate the design and
> complexity of the kernel.
>
> Dave...

Of course, now I'm thinking... piggybacking on GNO/ME, which is
already open source, and already runs on the GS... might be the best
bet. Then, it'd just be a few apps to get it going - a graphical
server app (and it's looking to me like GNO/ME might be able to do
native QuickDraw apps? Even if not, maybe it could be a GS/OS app...)
and then apps that take advantage of the graphical server.

The trickiest part would be allowing the graphical server to
gracefully "swap out" of the QuickDraw subsystem when a GS/OS app gets
launched. But, this GNO/ME-based approach might even let NDAs run
alongside these graphical apps.