DCS100@PSUVM.BITNET (David C. Schweisguth) (08/27/89)
A summary of my questions and the answers I received follows. Thanks to Messrs. Andy McFadden, Cary Farrier, and particularly Dave Lyons for their lengthy, thorough, and helpful responses. In article <89233.162153DCS100@PSUVM> I wrote: > 1) What are the purposes of the following files: [listing of several new >to System Disk 5.0 ...] The July 89 release of GS/OS Tech Note #1, just out from DTS, describes the contents of all three disks -- no sense duplicating it here. > 2) How does Expressload do its thing? Does it depend on the physical >placement of disk blocks, and if so will it be mucked up by copying >Expressloadable files with utilities other than the newest Installer or >Finder? No, it doesn't depend on the physical placement of disk blocks. Expressload uses a different object module format *within* the file, and not on any physical block addresses, so you should be able to copy any Expressload file (without a resource fork, see below ...) with any application. You'll get the maximum benefit if the file is not "fragmented" much, since a large part of the speed-up comes from being able to do Reads of large chunks of the file at a time, which usually translates to doing multiple-consecutive-block reads down at the device-driver level. (The SCSIHD.Driver and APPLEDISK3.5 drivers go Fast when they can do multiple-block reads.) > 3) Virus Detector V1.2 always detects a virus on copies of my presumably >virgin System Disk 5.0. It continues to do so after it has supposedly fixed >the boot block. This happens when VD is the first or last file in System/ >System.Setup; I haven't tried other placements. I guessed that a) the boot >block has been changed (as with GS/OS V2.0) and b) VD can't write over it for >some reason, but that's only a guess. Any ideas? (No, the disks on which I've >tried this have not been write-protected.) Interesting--I hadn't heard of this before, but I believe your guess is correct. The boot blocks *have* changed again (this time only to fix an obscure bug that only appears if your PRODOS file is Sparse and actually requires the zeroed-out bytes to be loaded into RAM). That explains why VD 1.2 doesn't like your boot block. So why can't it write a "good" boot block back to your boot disk? Because the Sys.Resources file is Open, and you can't write blocks to a volume with open files on it under System Software 5.0. > 4) Is the file System/Start.GS.OS supposed to be unlocked (if locked) or >written to during normal GS/OS operation? I normally keep all my non-document >files locked, and Start.GS.OS won't stay that way. The modification date is >still June 14th. This happened with System Disk 4.0 as well, but I never got >around to asking anyone about it. GS/OS keeps the "speed" of the boot thermometer in the auxiliary type of the Start.GS.OS file, so it's doing a SetFileInfo on that file. Apparently it doesn't bother to first do a GetFileInfo to preserve the access word. No big deal--just a little weird. > 5) I attempted to copy the entire system file-by-file from one 3.5" disk >to another using Copy II Plus. Only one block each of Sys.Resources, >Ctlpanel.NDA, Cdev.Data, and each of the CDevs made it to the target volume. >Copy II Plus did not report any errors. The Finder from System Disk 5.0 copied >the same files correctly. Are these (gulp) forked files? Yes. ("Extended" is the official word.) Apparently the version of Copy II Plus you were using [8.3] looked at the ProDOS storage type, saw that it wasn't a Tree file or a Sapling file, and decided it must be a Seedling file--and only copied the key block. Whoops! No idea if later versions of Copy II Plus know about extended files. > 6) There seems to be a bug in the standard file opening dialog. I have >two 3.5" drives, so when I want to load an existing document into an >application I normally boot the system from drive 1, launch the application >from drive 2, put the disk with the document in drive 2, and then open the >document. Under GS/OS V3.0 this sometimes hangs the system, as if it were >still expecting the application disk in drive 2. This only happens when I do >this immediately after launching the application (any application); after one >successful dialog everything works fine. I can work around it by selecting >Load, Open, or whatever with the application disk still in drive 2 and then >tabbing to the new disk, but I shouldn't have to. Has this happened to anyone >else? Any ideas? [A chorus of responses to the effect that these things happen all the time.] > 7) What would happen if I deleted the Control Panel NDA and its related >files (Ctrlpanel.NDA, CDev.Init, and the CDevs directory)? I haven't tried yet >but I might want a really stripped-down system some day, and they take up a >lot of space for something I don't use much. Amazingly enough, if you delete all that stuff, you get a disk that doesn't have a Control Panel NDA. This won't interfere with the system proper, but you won't be able to do Cdev-dependent things like choosing a printer. Thanks again, all. _____________________________________________________________________________ / \ | David C. Schweisguth 406 Althouse Laboratory "When one has much to | | AppleLink PE: Von Mordo University Park, PA 16802 put into them, a day | | Bitnet: DCS100@PSUVM 814-862-0806 (home) or has a thousand pockets."| | GEnie: D.SCHWEISGUT 814-863-2791 (work) -- Friedrich Nietzsche | \_____________________________________________________________________________/