Path: utzoo!attcan!uunet!unisoft!bdt!david
From: david@bdt.UUCP (David Beckemeyer)
Newsgroups: comp.sys.atari.st
Subject: Re: bios function 0x7f
Message-ID: <466@bdt.UUCP>
Date: 23 Dec 88 23:00:46 GMT
References: <12076@hall.cray.com> <3767@druhi.ATT.COM> <1263@atari.UUCP> <465@bdt.UUCP>
Reply-To: david@bdt.UUCP (David Beckemeyer)
Organization: Beckemeyer Development Tools, Oakland, CA
Lines: 59


In response to something Dan Moore said about illegal bios traps
returning a pointer to the bios jump table, Alan Pratt said:
>> Please do not rely on crap like this in your programs.  If you do, don't
>> expect them to work in the future.  Maybe I should make sure the hack
>> described above stops working, but I'm not vindictive or petty, so I
>> won't. 

Then Bob Rogers said:
>Mr. Pratt seems to be complaining about programmers using TOS in an illegal
>way.  Perhaps if Atari had ever bothered to publish good, widely available
>documentation his complaint would be valid.  Given Atari's disinterest in 
>documenting their machine I don't think Atari should complain too loudly
>when folks make mistakes.

You're both right.   Allan is correct that un-documented features shouldn't
be used, but Bob is also correct when he mentions that many "official"
features are (or at least were) effectively un-documented.   Dan Moore
also makes a good point about how many times in the past someone at
Atari has given mis-information, and now nobody there wants to take
any responsibility for it.

And then someone else discussed ways of informing developers before TOS
updates are released about changes that may break certain un-documented
features, saying:
>Developers who are still in business will have decent notice to
>remove dependence on such features (as a courtesy, Atari might privately
>inform developers whose products are known to be at risk, without promising
>that they'll do so).  Some orphan products will become useless to owners of
>new or upgraded machines, but that will just make more business for the
>remaining developers.

This brings us to the bigger problem that is really behind all this.

First, Atari has yet to attract the big developer bucks.  This means 
very few big-budget development efforts.   Especially the early ST
software, but it still applies today.  When you are working on a budget,
you can't always attract top-quality people and the end-result may
have more "hacks" than desired.   In addition, you can't devote a
lot of time tracking down information from Atari, especially in those
early days when it was almost impossible to get *any* information out
of Atari  (I really don't think anyone there knew much about the DRI
stuff yet).

The above applies to at least 90% of the Atari ST software projects.
There just aren't that many experienced software professionals getting
paid to develop Atari ST software.

Atari doesn't want to take the blame for it and neither do the software
developers.   So we end up with the Atari ST vernacular made up of
comments like "Developers who are still in business" and "orphan
products".  Without major investments by Atari, I don't see anything
more than a TRS-80 type market in the future either (i.e. lot's of
people that like the machine, but far outside the main-stream).
-- 
David Beckemeyer (david@bdt.UUCP)	| "Lester Moore - Four slugs from a .44
Beckemeyer Development Tools		|  no Les, no more."
478 Santa Clara Ave. Oakland, CA 94610	|   - Headstone at Boot Hill
UUCP: {uunet,ucbvax}!unisoft!bdt!david	|     Tombstone, AZ