🚀 go-pugleaf

In article <8908021826.AA05333@ucbvax.Berkeley.EDU> 01659@AECLCR.BITNET (Greg Csullog) writes:
>It drives me nuts to see so many people worrying about multitasking on the
>ST. Jeez, at 8 MHz on a 68000 without a co-processor, I'm having trouble
>getting good performance running one application at a time. If a CPU intensive
>app is running, I do not want to make it crawl any slower by asking the CPU
>to service another application. Hell, most people crave multitasking but until
>you have a 68030 and a co-processor or a 80386 and a co-processor, it ain't
>worth worrying about for 99% of the users.
>
>Want to run a word processor and a spreadsheet at the same time. No problem,
>get REVOLVER and switch between apps. Want to generate huge dbMAN reports
>and run .CMD files while executing another CPU intensive app - forget it!

First off, the majority of applications are user input driven.  Meaning that
if the user doesn't provide input, the program is idle.  For instance,
spread sheets, word processors, etc.  In a multi-tasking enviroment, such 
programs sleep when idle and take up no CPU time.  Using multi-tasking to
switch between applications like these would have the same affect as using 
REVOLVER.  Although I know nothing about REVOLVER, I imagine that it is only
a brute force way of getting some of the advantages of multi-tasking, and
I imagine it probably has quite a few limitations.  For instance, do you
have to tell it what applications you're going to run ahead of time, or can
you decide on the fly?  Does it work with ALL programs?  How easy is it to
start up a new process?  How much overhead does it require for each
application?

You asked for simple common uses for multi-tasking on the Amiga.  Here are
two of the more common, less demanding uses of multi-tasking that I do on my
Amiga 2000:

I do a considerable amount of programming (all just for sport, not for money).
One of the most common things that happens to me is that I'll make a change in 
one of the files of a 10 or so file program, like maybe change a structure
definition, and I'll have to figure out which other files need to be changed.
I'm already in the editor, but since I'm multi-tasking, and have a 
CLI (command line interpreter) sitting out there,  I click on the title bar
of my editor, making it turn into a small window and exposing the CLI window,
and type "grep foobar *.c *.h".  Better yet, since my editor can edit
multiple files, and since through multi-tasking, it can execute other
AmigaDOS commands, I can have my editor execute grep and put the results into
a file buffer.  Sure, I could have just exited from my editor, and then run
grep, but why make life harder, I have multi-tasking.

A more Joe Average use of multi-tasking occurs when ever I get a requester
saying "Disk Full".  This doesn't happen much anymore, since I just bought
an 80 Meg drive, but when all I had was a 20 Meg, it happened often.   When
ever I get one of these messages, I don't worry or get upset, I just click
on my CLI window, or press Left-Amiga-ESC (a key sequence which another
multi-tasking program intercepts and opens a new CLI window), and start
searching through my directory structure for files that can be deleted, or
compressed, or copied to another disk.  When I'm finished, I click on the
retry gadget of the Disk Full requester, and everything proceeds happily.
I don't know about the Atari, but if on an IBM, you get a Disk Full error
after you told your editor to save and exit, you have three choices: abort,
retry, or ignore.  Retry won't help any, ignore will give you a trashed file
and the editor will exit as soon as it thinks it saved the file, and abort
throws you back to the system prompt.  Any way you look at it, you're 
screwed.

The question "Why do you need multi-tasking on a personal computer?" is much
like the question "Why do you need more than 64k in a personal computer?"
which people were asking 8-10 years ago.  Once you have, you realize that
you can't live without it. 

A phrase that comes to mind: "Don't knock it til you've tried it."

Rich Champeaux  (rachamp@mbunix.mitre.org)