AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (03/06/89)
>Date: Sun, 5 Mar 89 07:27:51 GMT >From: Jeff Erickson <claris!krazy@DECWRL.DEC.COM> >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
krazy@claris.com (Jeff Erickson) (03/06/89)
> 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 ------------------------------------------------------------------------------
wombat@claris.com (Scott Lindsey) (03/06/89)
From articles <9004@claris.com>, by krazy@claris.com (Jeff Erickson): and another by David Lyons >> 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. The cache has a minimum of 16K in spite of what the DA says. I'm afraid I have to walk a narrow line between the general opinions of David & Jeff. I think that there are very few bugs in GS/OS itself. Granted it could be more solid, especially with the suggested cache. I know some of us at Claris are pushing Apple to try to get that on some future version. The tools are where I think most of the problems lie. Even if a program functions perfectly within its parameters (good joke) it's very likely to get screwed over by some flakiness in the tools. Apple *is* making progress in improving performance and thrashing out bugs, but I'm starting to feel its too late. The bugs do exist, both in the GS system and in the various Apple development systems. I AppleLink to DTS commonly 3-4 times a week. Granted not *all* of those are bug reports, but a reasonable percentage are. I'm not as bitter towards the GS as Jeff, but then I didn't work on TopDraw in the days of Gumby and the IIbf. I really wonder what direction Apple is trying to go with the GS. For what it tries to do (look like a Mac environ- ment) it really is too slow and lacking in screen resolution. > > I'm playing devil's advocate on this point. You're right. They ought > to read the f-ing manuals. So should we all. >>>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! If you have a Mac with only one floppy drive, expect to swap disks even more. >>>> 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. > > 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 can handle the OS telling me to switch disks and having to push the button myself. What I hate is having to hit return or click OK in order to tell it that I did it. The problem seems to be that Apple wants to straddle the fence. They want the GS to be Mac-ish, and they also want to be compatible with the old II stuff, like 5-1/4" drives. And they don't want special cases (if it's this kind of disk then look to see when it gets put back in... if there's only one floppy drive and the system is on a floppy eject ...) >>>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. Yeah, and it's not really a *lot* of trouble to use SFP[Get/Put]File to do it yourself. >>>[...] 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." The more you stress the system, the more problems will come to light. AWGS is one of the most (if not the most) system stressing applications available for the GS. > 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. I haven't given up on it yet. With GS/OS, they are laying some very firm foundations. The question is partly how much stuff is already built up that has to be knocked down for the foundation to go in place, and is it in time? Finally, in reference to something that I've managed to delete already, GS/OS being able to recognize disk-inserts. On the Mac (for one thing, the eject button does nothing) inserting a disk apparently generates an interrupt (or maybe the OS just polls) but at any rate it generates an event (type 4, which is undefined on the GS). This would be very nice to have on the GS, but once again, we have the compatibility issues to deal with. 5-1/4 drives again. The Event Mgr currently doesn't support disk inserts and applications that got them wouldn't know what to do with them. Sigh. To reiterate. The GS has potential. It needs more hardware power. But is it all too late? I consider the GS a nifty machine to program for. That's right -- "nifty." But it's about as real compared to a standard Mac as a standard Mac is compared to a VAX (maybe... maybe one of these days...) -- Scott Lindsey | UUCP: {ames,apple,portal,sun,voder}!claris!wombat Product Development | Internet: wombat@claris.com | AppleLink: LINDSEY1 Claris Corp. | These are not the opinions of Claris, Apple, (415) 960-4070 | StyleWare, the author, or anyone else living or dead.
blackman@phoenix.Princeton.EDU (Scott Michael Blackman) (03/07/89)
While we're talking about all the bugginess inherent in GS/OS and IIgs
tools, let me ask this:
Where and how should we report actual, verifiable bugs?
--
-- Scott "WhiteWoman" Blackman --------------------------------------------
__ ARPA: blackman@phoenix.princeton.edu, blackman@pucc.princeton.edu
[__] UUCP: {allegra}!princeton!(phoenix|pucc)!blackman
BITNET: blackman@phoenix.UUCP, blackman@pucc-Rich-@cup.portal.com (Richard Sherman Payne) (03/07/89)
After all this discussion, I'm amazed that nobody has figured out what was meant by "polling the drives," under GS/OS with a Unidisk. I *had* my old unidisk with my system at first. When I used GS/OS, it would check the drive every half second or so. I guess that the Unidisk cannot tell if there is a disk inserted, so the OS just keeps checking. After several hours of listening to the drive go on and off, you get a powerful urge to, well, disconnect the drive, at least. Counld not apple just put an IMW on the //e controller card, and let the Apple 3.5" drives be used on the //e? Then Apple could drop the Unidisk, and save on production and inventory costs. Rich -Rich-@cup.portal.com
krazy@claris.com (Jeff Erickson) (03/07/89)
From article <6863@phoenix.Princeton.EDU>, by blackman@phoenix.Princeton.EDU (Scott Michael Blackman): > While we're talking about all the bugginess inherent in GS/OS and IIgs > tools, let me ask this: > > Where and how should we report actual, verifiable bugs? The AppleLink address is AIIDTS ("Apple II Developer Tech Support"), if you're a registered developer. Otherwise, I don't know. -- Jeff Erickson \ Internet: krazy@claris.com AppleLink: Erickson4 Claris Corporation \ UUCP: {ames,apple,portal,sun,voder}!claris!krazy 415/960-2693 \________________________________________________________ ____________________/ "I'm so heppy I'm mizzabil!"