Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!AECLCR.BITNET!01659 From: 01659@AECLCR.BITNET (Greg Csullog) Newsgroups: comp.sys.atari.st Subject: Rebuttal time Message-ID: <8908252144.AA27005@ucbvax.Berkeley.EDU> Date: 25 Aug 89 21:45:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 76 >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.