Re: Idea: Multitasking graphical OS for the GS

[Tristan Mumford <mydotname@geemail.com>]

On Sat, 03 Jan 2009 03:08:52 -0800, Eric Rucker wrote:

> 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.

This quickdraw exclusivity issue also also plagued the mac systems too. 
It's just a general problem with the whole way it was designed.

Sure, you could easily have another app drawing to screen too, but it'd 
be a nice jumbled mess where it came across QD.

If you want to use existing GS/OS apps then use GS/OS.
Flip the idea upside down. Run GS/OS (or gno, which would probably make 
things a little neater...maybe. I don't know) and have a 'normal' gno or 
GS/OS program which has its own preemptive multitasking, program loading 
etc. to load programs written to comply with whatever APIs you may have 
written.
As an upshot of sitting it on top of everything else, you'd still have 
access to the toolboxes without any real finagling.

One more tangent from me:
On my pretty much stock Amiga 500 I tried a disk which among other things 
had an X10 server (as in predecessor to X11) and some demo apps that ran 
in it which were recompiled to run under AmigaOS, but of course used the 
X libs for I/O etc.
This cohabited with the native OS because they were really just apps. Now 
I do realise the differences in functionality between OSes (Although I 
was using 1.3 which was really pretty primitive). But if you ran gno 
programs compiled with libs to handle what is essentially a window 
manager app running in GS/OS, that could be another way of doing it.

Those are some ideas from me anyway. Hope that it can spark off some 
thought if nothing else.