[comp.sys.apple] GS/OS and potato chips

AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (03/06/89)

>Date:         Sat, 4 Mar 89 22:51:00 EST
>From:         ALBRO%NIEHS.BITNET@CUNYVM.CUNY.EDU
>Subject:      RE: info
>
>The defenders of GS/OS as the best thing since potatoe chips, and who
>blame all the dozen or so major GS programs and the bunch of CDAs and
>NDAs that crash using it on the programmers not following the
>guidelines should take a stab at answering two questions:

GS/OS it better than potato chips:  it has less salt and oil.

>(1) Why don't they follow the guidelines?  Do they WANT their
>programs to crash?  Seems a bit odd to me.  Historically, Apple has
>failed to follow the guidelines it sends to developers much more then
>they have.

They probably don't _want_ their programs to crash, but sometimes I
get the idea they don't really care that much, as long as it doesn't
crash too much off-the-shelf during demos at dealers.  If people buy
their product based on your expensive full-page magazine ads, what
incentive is there to make it actually work?

Reasons for not following guidelines:  laziness, apathy, or
stupidity.

Note that the ROM, tools, etc are _not_ required to follow the same
guidelines that application programs are.  Think about it:  if
something is _not guaranteed_ to stay a certain way, an application
can't assume that it will without causing problems in the future.
But the ROM and tools (and even things like the Finder, where you're
expected to use the version that comes on the system disk you're
using) can assume that things are they way they are--future system
disks will always contain updated versions of these things anyaw
(ROM patches, tools, etc).

By the way, failure to follow high-level guidelines is only one
problem area.  A lot of crashes come from "random memory trashing,"
whihc could be caused by any number of things, including:  not
checking for errors when allocating memory, not properly locking
down memory blocks during operations that allocate memory (or,
alternatively, not recalculating pointers to unlocked blocks after
such operations).  All sorts of careless mistakes using the toolbox
will result in memory being trashed.  Unfortunately, it is usually
not obvious when that is happening.  (Help is on the way, though.)

>(2) Has the "bad code" in a single one of the programs that crash
>under GS/OS been found yet?  Again, seems odd that no one has pointed
>out any of it.

As I said in another message:  PaintWorks Gold crashes under GS/OS
only if there is not enough memory available--it works fine
otherwise.  Tetris tries to allocate the bank-1 area that shadows
onto super-hires, and it goes ahead and uses it even if it was
already in use.  I don't have much experience with other big-time
applications, but I have found and reported specific problems in
numerous third-party NDAs and CDAs.

>The fact is that GS/OS (system 4.0) is new, and there has never been
>any operating system in the world that lacked a few bugs ("features")
>in its early versions.  If we accept the view that it is perfect and
>the rest of the world is perverse, it will never be improved.

We are _not_ seeing the "early versions" of GS/OS.  New systems disks
live a long and interesting life before they are seen by the public.
I never said it was perfect.

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