Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!ncar!boulder!tramp!walkerb
From: walkerb@tramp.Colorado.EDU (Brian Walker)
Newsgroups: comp.sys.atari.st
Subject: Re: bios function 0x7f
Message-ID: <5542@boulder.Colorado.EDU>
Date: 30 Dec 88 10:26:04 GMT
References: <1263@atari.UUCP> <3774@druhi.ATT.COM> <1268@atari.UUCP> <12401@hall.cray.com>
Sender: news@boulder.Colorado.EDU
Reply-To: walkerb@tramp.Colorado.EDU (Brian Walker)
Organization: University of Colorado, Boulder
Lines: 56

In article <12401@hall.cray.com> rosenkra@hall.UUCP (Bill Rosenkranz) writes:
>
>since i'm the horrible fiend who started this mess by asking a very simple
>question (which dan politely answered), let me just ask allan this: ok,
>fine. [...]
>in my own programs, i never rely on undocumented
>features, though many are tempting. you should either sh*t or get off the
>pot. make your beloved changes that break half the software (which sells
>your machines) of live with it and adapt to the often  pioneering efforts
>of us wcky developers. just don't throw a public tantrum, [...]
>
>if, on the other hand, atari is REALLY interested in being the
>number 2 or 3 pc in the world, grow up and start acting like ibm rather
>than some undisciplined wimpering child. kick some ass. [...]
>
>i just think this whole argument is a bunch of crap. since when has standards
>stood in the way of any (perceived) top-notch computer hardware/software
>company? besides, if atari fails, all this banter is just a lot of hot air
>anyway. who really cares? just EVOLVE. if that means ruffling some feathers,
>so be it...
>
It's nice to hear that some people follow the rules.

This discussion of the ongoing confrontation between OS designers and devlopers
is not new.  It is also not restricted to Atari.  Just ask Apple about this
problem.

I read in a recent issue of Byte Magazine (September, perhaps) about the Apples
Multi Finder system.  The article presented some of the enhancements added to
the system to support their multitasking environment and it presented some
of the fixes required to support all of the existing programs.  In short, the
folks at Apple were amazed at the number of programs that did not follow the
rules.  As a result, the curent version of Multi Finder includes many patches.
A few of those patches were included for the benefit of a single program.
This should not have been necessary.

The abuses of Apple developers forced Multi Finder designers to make 
unnecessary compromises.  Each compromise means that at least one efficient
way of performing a given operation becomes blocked and the designer must
choose a less efficient method.

Now put yourself in Allan's place.  You're in the middle of an ongoing process
to develope an efficient operating system.  Your team is playing with 196K of
low level coding which must be tweaked for maximum efficiency.  Then some bozo
comes along and decides to use a short-cut.  He's already told all of his
friends about his latest trick so you must grudgingly accept even though you
now have to accomodate that new feature.  That bozo just created more work for
you that was not necessary.  Futhermore, your freedom has been restricted so
now instead of that elegant solution you came up with, you have to gludge
something together and make it work.  Wouldn't you be a little upset?


Brian Walker, University of Colorado at Boulder
      walkerb@tramp.colorado.edu or {ncar,nbires}!boulder!tramp!walkerb
"If we imagine no worse of them than they of
 themselves, they may pass for excellent men."