Xref: utzoo comp.sys.mac:14039 comp.windows.misc:305
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hp-pcd!uoregon!omepd!mipos3!td2cad!cpocd2!howard
From: howard@cpocd2.UUCP (Howard A. Landman)
Newsgroups: comp.sys.mac,comp.windows.misc
Subject: Re: A/UX window systems, Mac tool...( Hum Interface)
Message-ID: <1174@cpocd2.UUCP>
Date: 14 Mar 88 18:01:05 GMT
References: <4129@hoptoad.uucp> <283@rhesus.primate.wisc.edu> <1710@ssc-vax.UUCP> <9829@steinmetz.steinmetz.UUCP> <7593@apple.Apple.Com> <3609@bloom-beacon.MIT.EDU> <7658@apple.Apple.Com>
Reply-To: howard@cpocd2.UUCP (Howard A. Landman)
Organization: Intel Corp. ASIC Systems Organization, Chandler AZ
Lines: 48
Keywords: window human computer interface

In article <7658@apple.Apple.Com> dwb@apple.UUCP (David W. Berry) writes:

>What I said was that MultiFinder still had some known areas where it
>could be improved.  Not that it was less than multitasking.  As
>a matter of fact it is fully and completely multitasking, non-
>premptive, but multitasking all the same.  Especially when one
>considers that all macintosh programs should be calling GetNextEvent
>periodically to interact with the user anyway, and task switching
>is done there.

You can see the problem but still don't admit it's there?  In real multitasking
NO SPECIAL CODING IS NEEDED.  Most programs multitask AUTOMATICALLY without any
special attention from the programmer.

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).  Why is this a problem?
Because it only takes one or two programs which fail to do this before
MultiFinder fails to grant any CPU time at all to the lowest priority task.
Why is this a problem?  Because there are lots of Mac programs out there which
were written before MultiFinder and are still useful, but which will never be
changed.  Companies go out of business.  Shareware authors move on to more
lucrative pursuits.  Etc.

I recognize that implementing real multitasking in a Mac environment is fairly
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.

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.

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.

-- 
	Howard A. Landman
	{oliveb,hplabs}!intelca!mipos3!cpocd2!howard
	howard%cpocd2.intel.com@RELAY.CS.NET