Xref: utzoo comp.sys.atari.st:6650 comp.sys.amiga:12224
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucbcad!ucbvax!cbosgd!mandrill!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.sys.atari.st,comp.sys.amiga
Subject: Re: Multi-tasking? A nightmare...
Message-ID: <886@neoucom.UUCP>
Date: 26 Dec 87 15:35:39 GMT
References: <2027@bath63.ux63.bath.ac.uk> <22237@ucbvax.BERKELEY.EDU> <4932@spool.cs.wisc.edu>
Organization: Northeastern Ohio Universities College of Medicine
Lines: 46
Summary: Could do task switching; but do you want to write that way?


I agree that Susan, John and the kids Averageuser family generally
does not need to do multitasking at the user level very often.
I've spent quite a few hours manning a user support center that
helped people deal with stuff from TRS DOS (chuckle) all the way to
big multiuser Unix environments.  The Averageusers almost always
approach the machine in a task-switched modality.  For instance,
they shrink down the editor window and go browse files for the
desired inclde text.  It is awful difficult to browse and type into
an editor simultaneously unless your've got four hands.

BUT....  Writing in a task-switched environment is difficult.  I've
worked with writing for MS-DOS windows which is a lot like writing
for the McIntosh and GEM/TOS environments.  You've got to be awful
careful about not stepping where you shouldn't be, behaving
yourself and being a "good citizen".  I find that dealing with the
fluff of such an environment is not insurmountable but does detract
from my productivity on addressing the desired programming end
product.

I much prefer working in an environment where the O/S does the dog
work of being a good citizen to the system resources.  Dynamic
control of task priority is also much easier with a real
multitasking O/S.  The enduser needn't really be aware that some
priority control is going on.  Such a benefit to the programmer is
to be able to control how much time a print spooler gets.  When the
user is doing hunt-'n-peck, the print priority can be high, and
then knocked down when a spelling check is begun.

The whole point is that while the enduser may not use the features
of a multitasking O/S directly at a high level, it makes life
easier for us to develop tools for the enduser.  Even if the
enduser tools themselves don't take advantage of multitasking,
being able to develop under a multitasking envronment allows us to
be more productive and shorten the lead time in delivering the
product to the enduser.  This means for sales (ching ching) for us;
and that's what matters most, right?

OK, here's an example that really can't be done without a
multitasking O/S:  the Mimetics Pro Midi Studio.  It is diffiult to
explain exactly what Pro Midi Studio is like without actually
seeing it run.  It is true that PMS addresses a relatively small
market segment, but applications for other users just haven't been
thought up yet.

Happy holidays,
--Bill