Re: Idea: Multitasking graphical OS for the GS

[Eric Rucker <bhtooefr@gmail.com>]

On Jan 9, 8:20 pm, Tristan Mumford <mydotn...@geemail.com> wrote:
> 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.

That's actually exactly the idea I had, and someone thought of it long
ago, and did one for GNO already. ;)

It was called DRWM.