Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!claris!wombat From: wombat@claris.com (Scott Lindsey) Newsgroups: comp.sys.apple Subject: Re: GS/OS and programming standard Message-ID: <9007@claris.com> Date: 6 Mar 89 05:55:29 GMT References: <9004@claris.com> Organization: Claris Corporation, Mountain View CA Lines: 155 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.