Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!claris!krazy From: krazy@claris.com (Jeff Erickson) Newsgroups: comp.sys.apple Subject: Re: GS/OS and programming standard Message-ID: <9004@claris.com> Date: 6 Mar 89 01:06:02 GMT References: <8903051629.aa07623@SMOKE.BRL.MIL> Organization: Claris Corporation, Mountain View CA Lines: 126 > David A. Lyons >> Me > 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. > That's great, but my application has to run under GS/OS. This means I have to test it under GS/OS. Period. I understand the problem: GS/OS doesn't checksum its cache. In the light of the fact that new application HAVE to be tested under this operating system, that's unforgivable. In any case, my disk cache has been set at 0k for as long as I can remember, at least according to the NDA. >>... 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.) System 2.1? That new? I'm sorry, I was refferring to things back in the old ProDOS 8 days. A lot of assumptions have been incorrectly carried by old P8 programmers. You're right. It's there in black and white. But a lot of Apple// hackers just make the assumption.... I'm playing devil's advocate on this point. You're right. They ought to read the f-ing manuals. > >>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. > I have. They fixed most of them. My point was, Jeremy should expect to swap disks a lot with only one drive. >>> Uhhh...HOW is GS/OS supposed to know when to eject a disk? The >>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. Now I know. But if it's so trivial, why don't the tools do it for you, like the Mac tools do. Sure, the application CAN eject the disk itself, but I don't know of any that DO. >>I once asked Apple's Developer Tech Support why the standard file >>dialogs didn't have an "Eject" 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. When I asked, I was wondering why they weren't being more consistent with the Mac interface they are trying to emulate. No need, per se, I just thought it would be NICE. >>[...] 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. Please, let's not get into "I'm more qualified to talk about the machine than you are" arguments. I've reported bugs in prerelease system software, and most of them have been fixed. Not all. Most recently, the responses sounded something like "yeah, that's a bug, but it's too late, we've already released the system. You'll have to figure out some way to work around it. Sorry." There are some really good people working on the IIgs at Apple, and there are some really awful ones, too. While it is true that old bugs have been fixed, and old problems have been resolved, it has never been the case the that a released version of IIgs system software was free from major problems. The closest they ever came was System 3.2. It may not be very "useful" to claim the the system is very buggy, but it it absolutely true. I don't have the faith in this machine that you obviously do. I've given up on it. [Once again: MY OPINIONS, NOT CLARIS'S, GOT IT?] -- Any opinions you read here are only opinions in my opinion. Jeff Erickson krazy@claris.com "I'm so heppy I'm mizzabil!" -- Krazy Kat ------------------------------------------------------------------------------