From: bmccnnll@unix1.tcd.ie (Barry McConnell)
Subject: Re: the NeXT option (Was Re: 7.1 vs. OS/2 and Windows NT)
Organization: Trinity College, Dublin
Date: Sun, 11 Oct 1992 00:05:11 GMT

In <ewright.718660745@convex.convex.com> ewright@convex.com (Edward V. Wright) writes:

>Well, no, you've just proven that the Amiga, like the Macintosh,
>has cooperative multitasking.

Wrong.

>The only time it can multitask is when an application permits it. 

Wrong. It multitasks all the time, until an application explicitly turns it
off. Take *any* platform: there will always be a way - however system un-
friendly - to lock out the OS.

>If an application doesn't
>cooperate by using Permit() calls at the appropriate times (after
>a Forbid() call), multitasking can't occur.

Applications rarely use Forbid(). They shouldn't, unless there is a damn good
reason for it. There is just no need. So of course, if they "forget" (ha!) to
call Permit(), you'll end up with a dead machine... It's called a "bug".

>Who is "you?" Does the user set that priority, or the program?  

A program, controlled by the user. :-)  An application can, of course, change
its priority if it feels like it (e.g. if it sees that the user has just typed
"-5" into the "Priority" field in one of its Preferences windows), and you can
use 3rd-party software to get a list of every task in the system, and change its
priority. 

>If it's the user, it's got to be damned annoying to fiddle with
>the priorities setting everytime you change to a different paint
>tool.

You don't have to fiddle with priorities at all if you don't want. Just leave
all applications at zero, and the system will multitask peacefully. It's when
you have complicated issues like "I want to ensure that this comms software
doesn't drop characters just because I have LhA, uuencode, and a mandelbrot-
generator going in the background" that you might think about bumping up the
priority a little.

>It depends on programs cooperating and not just cranking their priority up to
>5 all the time.

Oh for heaven's sake. Your Mac's successful operation depends on all your
software being written correctly. What's your point? Do you think people set
out to write unfriendly programs?

>I also think you're confusing "customizable" and "friendly."  One
>feature Mac users complain about (justifiably) is having to calculate
>and set appropriate-sized memory partitions for each program. Setting
>priorities is the same thing, applied to CPU cycles instead of RAM
>space.  What makes one friendlier than the other? 

You might justify having co-operative multitasking in that it's a lot easier
to use from the end user's point of view. But pre-emptive is just the same;
it's "hidden" from the ordinary user, but for the "power" user, it is very
customisable. This is - I think - one of the problems with the Mac; it's very
easy to use, but that makes for limited options when you want to go further 
with it. The idea of having some complicated mechanisms which take a little bit
of thinking about seems to be outside the rules set by Apple...

Having multitasking does not cause problems like having fixed-sized memory
chunks for each application does. The latter is a limitation; the former is
freedom.

>This has nothing to do with multitasking; it's a user interface
>issue.  A modal dialog, by definition, does not allow you to do
>other things while it's open.  That's because a modal dialog box
>is meant for situations that require immediate interaction between
>the application and the user.  If immediate interaction is not
>required, the programmer should use a nonmodal dialog box instead.

Nothing should require "immediate" attention. An "Are you really sure?" dialog
box might prompt me to go back to the Finder and check the contents of that 
file before it's deleted. A "Disk full - Cancel, cancel, or cancel?"-style
box is really annoying, when on the Amiga I could go back to the desktop,
browse around for a while, delete a few files, then hop back to the requestor
and click "Retry".

>And, ah, what happens to the Amiga when a programmer fails to
>match up every call to Forbid() with a call to Permit() ?

What happens to the Mac when a programmer leaves a bug in his code?

Barry.