Re: Idea: Multitasking graphical OS for the GS

[Eric Rucker <bhtooefr@gmail.com>]

On Jan 2, 1:16 pm, "Jeff Blakeney"
<jeff.blake...@a2central.com.remove-11i-this> wrote:
>   To: Eric Rucker
>
> On Thu, 1 Jan 2009 13:56:09 -0800, 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. ;))
>
> I too have often thought about how to improve the operating system for
> the IIgs.
>
> My thinking over the years has been to start with the toolbox.  The
> biggest thing stopping preemptive multitasking that I've come across is
> that the toolbox routines are not reentrant so you can't interrupt a
> process while it is in a toolbox call.  Another problem is that every
> program that runs under GS/OS has to allocate direct page space for
> iteself and for many of the toolboxes it uses.  I figured if the toolbox
> routines were written to be reentrant and their scratch pad memory that
> they need were moved out of the direct page to regular RAM, you'd be
> well on the way to being able to create a preemptive multitasking
> system.  Moving the toolbox direct page memory to regular RAM would
> cause a small performance hit but I believe that would be more than
> compensated by the fact that you'd have more direct page space available
> so you could have more applications running at once.
>
> My brother and I have discussed operating systems in the past as well
> and an idea we came up with could potentially remove all the message
> loops in a program and causing less context switching.  Instead of doing
> an event loop like so:
>
>     Do
>         GetMessage
>         DispatchMessage
>     Loop Until Done
>
> You would instead, tell the operating system when each function in your
> code is to be called.  For example, in a contact management program, you
> could tell the operating system that when the selection in the listbox
> of contacts changes, to call a subroutine that will fill in the rest of
> the fields on a form with detailed data about that contact.  In effect,
> the loop above would only ever be performed by the operating system and
> your code would only ever execute if the conditions you stipulate arise.
> That way, if your program is simply waiting for user input and not
> performing any background tasks, it will never take any CPU time until
> you interact with it in some way.  Basically, the DispatchMessage call
> would have to create a new thread for the routine to run in and kill it
> when the routine finishes.  This could be tricky to achieve but it sure
> sounds like it has potential.

Well, the Minix book suggests another way of doing things...
essentially, having the program sleep, which means the OS stops giving
it CPU time, until it receives a signal from the OS. This wouldn't be
a running loop, the program would halt execution until the OS sent the
signal, at which point the program would be sent into its signal-
handling routine.

At least, that's what my 2 AM reading through that section gave me.