🚀 go-pugleaf

In article <1174@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes:
>Under MultiFinder, each program (except possibly the last one) must be
>specially coded to be "MultiFinder compatible" by calling WaitNextEvent instead
>of GetNextEvent (if I don't have them reversed).

No.  MultiFinder works just fine with existing apps.  Using _WaitNetxEvent
is just optimization, just like using sleep() in Unix.

>tricky.  The main problem with any multitasking is handling conflicts when
>more than one program wants to use a limited resource, such as a printer port.
>What makes this more difficult on a Mac is that THE SCREEN IS A LIMITED
>RESOURCE which has to be carefully managed, and almost every program wants the
>screen to itself while it's running.
>

No, almost every program does *not* want the screen to itself while it's
running.  Applications are very good about only drawing in windows, so it is
fairly simple to extend the windows metaphor to layers.

>The original Mac solution to this was not to multitask.
>
>This was too restrictive, so Switcher was invented AS A KLUDGE to allow some
>of the benefits of multitasking.  But still nothing could run in the
>background.
>
>This was too restrictive, so MultiFinder was invented AS A KLUDGE to allow
>background tasks to run IF THEY WERE SPECIALLY CODED.  But not everything is,
>or ever will be.
>

No.  The only reason that it was decided to force applications to notify the
OS that they needed bg time was that most Mac applications don't have anything
useful to do in the background, so they are wasting time.  Again, this is
simply an optimization, NOT A KLUDGE.  It would have been possible to
allow them all to run in the background, but wasteful.

Also, NO SPECIAL CODING is required to run in the background.  The SIZE
resource has a "canBackground" bit, which can be changed by anyone, not
just the application's developer.  If you have an app you wish to run in the
background, just set the bit.  It will require ResEdit, but if you are an
active user of shareware and public domain programs that might never be
revved, then odds are you have a copy of ResEdit too.

>This is too restrictive, so Apple will eventually be forced to actually solve
>the problem, possibly by melding some feature of AUX into the Mac OS.

Probably the other way around.  As A/UX handles more and more of the Mac
interface, it will have to deal with these same problems, and it will
probably include the same optimizations to increase performance and
response time, to provide the Mac "look and feel."

-Phil Goldman
Apple Computer