Re: Idea: Multitasking graphical OS for the GS

On Jan 2, 1:16 pm, "Jeff Blakeney"
<jeff.blake...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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.
.

Relevant Pages

  • Re: Idea: Multitasking graphical OS for the GS
    ... interesting if there were a semi-modern, multitasking, graphical OS ... The Manager on GS/OS does NOT qualify. ... My thinking over the years has been to start with the toolbox. ... tell the operating system when each function in your ...
    (comp.sys.apple2)
  • Re: OWC11 Not coming For webpage....
    ... Your parse routine should be something like this ... chart from microsoft office xp web components. ... in toolbox i do right click and i choose "choose items" from com ...
    (microsoft.public.office.developer.web.components)
  • Re: Mens Hour Books
    ... the effort to weed out because the organism (the operating system) is ... computers a thousand times faster than those ten years ago, ... Suppose you have a routine which *almost* works. ... they need to retain the old API. ...
    (rec.arts.sf.composition)
  • Re: How to anticipate errors using On Error GoTo
    ... I will probably start with a basic routine and work with it as we go along. ... the operating system will catch any errors ... with user interaction so a user can get feedback, ... and 3) those that occur in batch processing. ...
    (microsoft.public.vb.general.discussion)
  • Re: open a file once or repeatedly within a loop
    ... Should I worry about the file if my script crashes in the loop while the file is open? ... And wont even hand it over to the operating system at all if it crashes. ... I had extreme problems with one aspect of PHP's file handling - moving an uploaded file and then LOAD-ing it into a database simply failed: the file movement didn't happen at OS level until PHP exited. ... I cant answer for php, but C-wise, fclose really doesn't do more than fflush, except to release the internal memory structures. ...
    (comp.lang.php)
Loading