Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!ucbvax!UIAMVS.BITNET!AWCTTYPA From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") Newsgroups: comp.sys.apple Subject: GS/OS and programming standard Message-ID: <8903051629.aa07623@SMOKE.BRL.MIL> Date: 5 Mar 89 21:58:51 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 124 X-Unparsable-Date: Sunday 05 Mar 89 3:29 PM CT >Date: Sun, 5 Mar 89 07:27:51 GMT >From: Jeff Erickson >Subject: Re: GS/OS and programming standards > >The problem with David's statement is that GS/OS occasionally does >some of the stupid things he describes, or at least seems to. During >development of the most recent project I worked on, GS/OS caused the >death of my hard drive on about seven different occasions, over the >space of three months. I have the drivers/FSTs installed correctly. >Other people working on the same project who stuck with P16 did not >have the problems I did. > >Admittedly, you can't expect a program under development to be >free of random memory writing, but as I said, P16 was MUCH more >tolerant. GS/OS did not _cause_ the death of your hard-drive volume; it only assisted in its death. When your program trashes memory at random, it can hit a cached image of a directory block. If the damage does not make the cached block completely unusable, the next time you, say, create a file in that directory, GS/OS will read the damaged block from the cache, change it, and write it back to disk. Ouch. I would be a happier person if GS/OS kept checksums on its cached blocks--not because it is buggy, but to limit the damage when buggy utilities or applications-under-development accidentally tromp on the cache. This seems obvious, but I do _not_ recommend you test your _under-development_ applications under GS/OS with a hard drive turned on, unless the volume is expendable. I have trouble feeling sympathetic for you since you let it happen SEVEN TIMES. >The standards used by GS/OS are, by and large, not new. There are >some things which always worked under ProDOS which will no longer >work, (like assuming devides named .d1, .d2, etc.) , but haven't >always been warned against. A conservative programmer never makes >assumptions about what the system will do, but it's not always easy >to tell the difference between an assumption and an accepted >standard. It usually isn't hard at all. The D_INFO call was added at System Disk 2.1 and documented in the release notes dated August 11, 1987. As I recall, there was a document available at about that time saying in very plain terms _never_ to assume that device names would have the form ".Dn". (Unfortunately, the Addison-Wesley P16 manual doesn't seem to make it clear at all.) >If Jeremy has JUST a UniDisk on his system, I can see one source of >his problems. The system disk has no room for anything else. Despite >David's claims, the TOOLS expect the system disk to be online at all >times. If you expect to USE your IIgs with only one floppy drive, >and you have GS/OS, expect to swap disks a lot! > >For the most part, (ie, to the best of my knowledge), the tools know >when to either ask for the system disk or return an error to the >application if the disk isn't there. This seems to be a contradiction. Certainly the tools should behave nicely when the system disk is not online, and so should applications. If you have found any cases where the tools don't behave appropriately, please report them to Apple II DTS pronto. >> Uhhh...HOW is GS/OS supposed to know when to eject a disk? The >> application has to figure that out (it's trivial for an application >> to ask GS/OS to eject a disk; not so under ProDOS 16). >> [...] >> There is currently no better way for the Finder to always notice >> when you insert a disk than to poll the drives.... > >The Mac OS ejects disks; there isn't any reason Apple couldn't do the >same thing with GS/OS. And as far as I know, there is no GS/OS call >to eject the disk. GS/OS ejects disks at the application's request, just like Mac OS. Check the _GS/OS Reference, Volume 1_ beta draft from APDA, page 108. The DControl call ($202E) can be used with a parameter count of 2, first parameter = devNum, second parameter is code, (code=2 is Eject). I _said_ it was trivial under GS/OS. It's trivial. >I know the Finder does it; that was a hack that Dan Oliver (the >original author) put in. Yes, under ProDOS 16 ejecting disks is a mess. >I once asked Apple's Developer Tech Support why the standard file >dialogs didn't have an "Eject" button. They said they'd ask the >engineers. The engineers must not have told them. (Presumably it >has something to with 5 1/4" disks, which can't be software-ejected, >but that doesn't explain why they couldn't add an extra button.) I don't see any reason they couldn't. I also don't see a big need for it, although there are a _few_ people out there using drives with no Eject buttons on them. >As for polling the drives, that's a hardware/firmware constraint of >the UniDisk. But the GS also polls Apple 3.5's (the gray ones that >work on the Mac, too), even though the Mac doesn't. I'm not certain, >but I belive it is possible to tell the two apart from software. I don't know how the Mac knows a disk has been inserted. If it can be done the same way with the GS hardware, I want to hear about it. >[...] The support from within Apple for the development (if not the >survival) of the IIgs has been, in my personal opinion, abysmal >(sp?). The system is buggy. VERY buggy. After having worked on the >machine for two and a half years (I started with an Apple II Gumby at >StyleWare), I honestly can't say that I expect things to get better. It isn't terribly useful to assert that the system is "very buggy." I don't agree. I've worked with the machine for just as long (although not in a big-name company). I've reported a lot of bugs over the years (mostly _not_ in publicly-available system disk releases), and the bugs have been fixed. I've made suggestions, and some of them have been taken. I could be certainly be happier, but I fully expect things to _continue_ to get better. [Jeff's opinions are his own, and my opinions are my own.] >Jeff Erickson krazy@claris.com --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons