Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!ucbvax!UIAMVS.BITNET!AWCTTYPA
From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons")
Newsgroups: comp.sys.apple
Subject: GS/OS bugginess?
Message-ID: <8903060413.aa11956@SMOKE.BRL.MIL>
Date: 6 Mar 89 09:46:52 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 80
X-Unparsable-Date: Monday 06 Mar 89 3:13 AM CT

>Date:         Mon, 6 Mar 89 01:06:02 GMT
>From:         Jeff Erickson <claris!krazy@APPLE.COM>
>Subject:      Re: GS/OS and programming standard

>> 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.

I didn't say not to test it with GS/OS.  I said not with a
non-expendable hard drive!  If you don't want to boot GS/OS off of
3.5 drives, surely your employer can afford extra HDs for testing
purposes, so you can keep your important ones offline during testing.

>In any case, my disk cache has been set at 0k for as long as I can
>remember, at least according to the NDA.

When you set the cache size to 0, there is still a 16K cache inside.
You can't turn it off completely.  (This info comes from the team
that wrote it, from Apple II Development chats on ALPE in recent
months.)

>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.

That's news to me--I always assumed that applications on the Mac
were responsible for asking the system to eject disks.  If not, how
does/should it work?  Should GS/OS eject a disk, chosen at random?,
whenever it would report "volume not found"?  How can it know
whether the disk you're about to insert is a 3.5, a 5.25, a CD-ROM
disk, etc, given only the disk's name?

>>I once asked Apple's Developer Tech Support why the standard file
>>dialogs didn't have an "Eject" button....
>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.

I object to the implication that there's nothing more behind the GS
toolbox design than wanting to be the Mac's little brother.  Things
like the SF Eject button aren't strictly necessary for the GS, so
there is a difference in the way Standard File looks.  (That's not
the only difference.)  But there are things the GS has done better
than the Mac, too--like window scroll bars that show you how much
of the content you're seeing, and TaskMaster.

>> 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 [...]
>
>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.

That wasn't my intention--sorry if it sounded that way.  My point was
that if System 4.0 is as buggy as you make it sound, I'd much rather
hear _specific_ bug reports.  I haven't had many problems.

>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."

That sounds like a reasonable _partial_ response to me.  They can't
fix it _retroactively_...you have to work around it until the next
system disk release.  I have a lot of trouble imagining them saying
"Yeah, it's a bug, and we like it.  We're keeping it."

>         Any opinions you read here are only opinions in my opinion.
>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