Xref: utzoo comp.sys.amiga.misc:222 comp.sys.amiga.advocacy:212
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!shelby!neon!torrie
From: torrie@cs.stanford.edu (Evan J Torrie)
Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.advocacy
Subject: Re: Multitasking.
Message-ID: <1991Jan23.220241.853@Neon.Stanford.EDU>
Date: 23 Jan 91 22:02:41 GMT
References: <1991Jan21.032207.6127@cunixf.cc.columbia.edu> <4827@skye.cs.ed.ac.uk> <12913@life.ai.mit.edu> <12916@life.ai.mit.edu>
Sender: torrie@Neon.Stanford.EDU (Evan James Torrie)
Organization: Computer Science Department, Stanford University
Lines: 84

rjc@geech.ai.mit.edu (Ray Cromwell) writes:

>  The Mac programmer must decide CAREFULLY where to place I/O calls to 
>give up the CPU. If the compute loop is sufficiently complex( nested),
>he will have to put them in many places.

  Yes.  This is the failing of the Mac multitasking system.  You HAVE
to be a clever programmer to decide where to give up control.  On the
Amiga, it doesn't matter how bad a programmer you are, the OS will
come to your rescue... :-)

>  I suspect the Mac's lack of priorities and preemptive tasking would cause
>foreground tasks to become jerky if compute intensive tasks are placed in
>the background (such as a long ray-trace).

  Only if the compute intensive task doesn't yield the CPU often
enough...  With the commercial ray-tracer I use on the Mac, I notice a
slowing down in the word processor on top, but it doesn't get jerky.


>On the Amiga, programming rules about multitasking have been around
>since day one. However, on the Mac, I suspect the vast quantities of
>software published before Multifinder was invented will be CPU hogs.

  Yes.  Luckily, there are few programs published before MultiFinder
which haven't had an update since the advent of MultiFinder.
[Actually, this is an interesting computer history lesson.  Get out
your copy of Mac/AmigaWorld from four years ago.  Go through all the
advertisements and see how many of those programs are still in
existence today in the same state as they were four years ago....
probably not very many]


>The Amiga faces the same problem with device independent graphics.
>Most Amiga programs assume bitplaned graphics and alot of them write
>directly to display memory. It will be hard for the Amiga to become device
>independent and still work with older programs. 

  Even Amigaoids will agree that this is one area where Apple has an advantage.

>The MS-DOS world has
>an even bigger problem. No matter how many kludges IBM companies come up
>with, they will always have to contend with MS-DOS and 8088 compatibility.
>If they don't, they have to break millions of dollars of software out
>there. 

  Eventually, though, the old software becomes obsolescent...  the
time it takes for this to happen depends on the size of your installed
base.  For example, Apple essentially no longer supports 64K ROM
machines... eventually they will start phasing out support for non 1.44MB
floppy disk machines [perhaps even as soon as System 7.0, which won't
fit on 800K disks].
  Most IBM software now assumes an 80286 at least.  Perhaps by the
time they get out to 32-bit Windows and an assumed 80386, they will
start to drop off support for the segmented memory model of the
8088/286.  I see this happening sometime around the year 2010 :-)

>  Now look at the Mac. Apple is attempting to layer a multitasking
>interface ontop of a non-multitasking core. 

  Luckily, I think Apple will give up on this, and either rewrite the
Mac OS from the bottom up, or just migrate everybody to a variant of
A/UX.

>This is almost the same
>as layering MS Windows ontop of MS-DOS. As far as I know, the Mac
>has none of the facilities the Amiga has for sharing interupts,
>exceptions, handlers devices, console windows, keyboard strokes.
>Consider the Amiga's Task Control Block, or struct Process, can anybody
>tell me what the Mac equivelent is?

  Apple's Process Manager (which was internal knowledge only in System
6.0), will be an integral part of System 7.0, and calls to spin off
processes etc will be available (according to a talk I went to at
MacWorld).





-- 
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu   
Fame, fame, fame...  What's it good for?  Ab-so-lute-ly nothing