🚀 go-pugleaf

>in article <8908160401.AA01009@ucbvax.Berkeley.EDU>, 01659@AECLCR.BITNET (Greg
>Csullog) says:

>> Look, I can format floppies from within all my ST applications,

>But you have to either have the Format command available as a desk accessory
>(don't know if it's possible?), or each individual program must worry about
>including a disk format option.  Certainly if that's important to the market,
>most will, but it's still something a program's author shouldn't have to
>worry about -- debugging the real application should occupy all their time.
>Plus, when I format a floppy, I can click back to my WordProcessor or
>Terminal or whatever else I have running, while the format takes place.

Obviously, you are not aware of the Universal Item Selector for the ST. Yes,
I agree it's not fun to wait to format a floppy and being able to do another
task at the same time would be helpful. However, is this REALLY the key
factor in having a multitasking system? Surely not! In eight years of using
micros (HP, PC, DEC, ST, Mac) I cannot recall more than 5 or 6 times I had
to format a floppy while running an application and when I had to, with
the UIS for example, I had to wait for the floppy to be ready to continue
my work - that's why I formatted it! I was not willing to jump to another
application just so I could kill one minute.

>> I can run a word processor, a spreadsheet and a painting program at the same
>> time and switch between them.

>But you can't have the word processor ask the data base to find you client
>files, extract some data, pass it to the spreadsheet, generate a color
>image, then pass that to the paint program for conversion to black and
>while, before being inserted into your word processor.  You need several
>programs active for that kind of interaction.

Obviously, you are not familiar with REVOLVER either. On one occasion, I was
using LDW (a LOTUS clone) and dbMAN (a dBASE III plus clone) at the same time.
I run a small VAR dealership selling STs and I have some data on a spread-
sheet and some on a database. These applications were in different memory
partitions while I compared data as I switched between them. I extracted
data from the sheet, passed it to a common RAM disk for the partitions and
imported the info into the database. Then, from a third partition, where
I was running my word processor, I read in the extracted data to include it
in a tax report I was preparing. If I wanted, I could have just as easily
run either my DTP or a graphics program in another partition to share data
via the RAM disk. BUT, I was doing task switching, NOT multitasking as each
application is suspended as I switch partitions. However, it's no big deal
in this instance as each application I switch out of does not have to do
anything after I switch out.

REVOLVER also has another great feature. I can roll out a 1 meg partition
from RAM to about 300K on disk. In effect, the application is frozen on disk
and when rolled back in, I can pick up exactly where I left off. As such,
I can roll many applications in and out (and quickly) to free me of some
of the restrictions that are imposed by available memory and are only over-
come using virtual memory.

Still more on REVOLVER. Suppose I am programming in one partition while
another application sits in another. Whoops, I crash my ST because my code
is buggy. No problem, the common RAM disk stays intact and ONLY THE
PARTITION THAT CRASHED NEEDS TO BE REBOOTED. The other partition(s) remain
unaffected as if I had two or more STs side by side. Now that's the kind
of stuff I like!

>>BUT, when I want to crank out dbMAN reports from my databases (one is
>>almost 4 megabytes), I don't want to slow down my 68000 by using another
>>application at all. I want the dbMAN stuff out asap.

>DataBase stuff is often disk intensive.  If my DB program is thumbing through
>100 megs of database to prepare a report, I'll likely have lots of CPU time
>left for other stuff.

Not in my case, I do a lot of number crunching in conjunction with data look
ups based on search conditions. I have imported my dBASE III work from my
AT at work to my ST because dbMAN is faster in the same job. We have dBASE IV
at work that is faster to use once codes are developed and compiled but
ASHTON-TATE has taken a giant step backwards in its user interface for IV.
The whole thing is more cumbersome and much slower than III's interface.