[comp.sys.atari.st] Pexec Cookbook, and pseudolegal system calls...

kbad@atari.UUCP (Ken Badertscher) (04/02/89)

  Several people have asked how to get the Pexec Cookbook.  It is
available to registered developers, who can find it in the usual online
places.  It will also be included with the TOS 1.4 release notes, which
will be sent to all* registered developers.  It is also being folded
into the developer documentation, so if you buy that documentation, you
can get it that way too.  Complete Atari ST developer documentation (not
schematics, they are available seperately) is available from Atari Corp. 
for $100.  If you're looking for "real" ST documentation, this is the
first and best place to get the inside facts.  Believe me, you get quite
a stack of documentation for your hard-earned C-note!

================

In article <1409@atari.UUCP> I wrote:
>As someone mentioned, there is the shel_get call.  However, it only
>returns the address of the AES internal buffer which is sometimes used
>to store DESKTOP.INF data, ***AND*** the format of that buffer is
>SUBJECT TO CHANGE WITHOUT NOTICE.
>  In other words, don't try to use what you find there, or your software
>will surely break in the future.
 ... 
>it is NOT a good idea to go peeking
>around in the AES' private variable space.  The AES and Desktop are a
>very tangled intertwining convoluted piece of work, and you stand a very
>good chance of breaking something before you would add a useful
>enhancement if you tried to modify the way the Desktop handles window
>templates.

Ignac Kolenko writes:
 if the shel_get() call returns values which are *internal* to the desktop
 only, then why, oh why, is this call sitting around for us programmers
 to use???????????????? The tos 1.4 developer docs do not say that there
 is anything inherently wrong with using shel_get()!!! (i had to phone
 a friend who has the docs to find out this info)
 
Quite a few things in TOS are documented and have no useful function.
That does not mean that programmers can or should have carte blanche to
use these features.  Nor should anyone assume that the useless features
will retain the same behavior in future TOS revisions.  It is
unfortunate that the BETA TOS developer documentation was unclear on the
lack of usefulness of the shel_put() and shel_get() AES calls, but that
oversight will be corrected in the final release notes.
 
  Don't do illegal stuff with your software, please.  We are no longer
constrained to strict software compatibility in future TOS revisions,
and I, for one, intend to take advantage of that fact.  This means that
I will be implementing enhancements which will almost certainly break
software that either a) didn't follow the rules in the first place, or
b) was built on bad assumptions about the internal workings of TOS.
 
  P.S.  Have a nice day. ;-)
-- 
 Ken Badertscher                 | #include <disclaimer>
 Atari R&D                       | No pith, just a path:
 Software Engine                 |   {portal,ames,imagen}!atari!kbad

rogers@ncrcce.StPaul.NCR.COM (Bob Rogers) (04/04/89)

In article <1423@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
>....  Complete Atari ST developer documentation (not
>schematics, they are available seperately) is available from Atari Corp. 
>for $100.  If you're looking for "real" ST documentation, this is the
>first and best place to get the inside facts.  Believe me, you get quite
>a stack of documentation for your hard-earned C-note!

Do you folks _ever_ intend to publish this information in a readily available
and affordable format?  I can go to my local Software Etc. store and get 
detailed technical info on PCs, Amigas, Macs, Apple IIs, GSs, even Commodore
64s -- but not for the ST!  From what I saw of the developer's docs (I saw a 
copy a couple of years ago) they're not professional quality documentation.

>  Don't do illegal stuff with your software, please.  We are no longer
>constrained to strict software compatibility in future TOS revisions,
>and I, for one, intend to take advantage of that fact.  This means that
>I will be implementing enhancements which will almost certainly break
>software that either a) didn't follow the rules in the first place, or
>b) was built on bad assumptions about the internal workings of TOS.

Given the tiny percentage of the market that the ST has, and the tiny number 
of (mostly tiny) companies that write software for it, can you really afford
to "certainly break software"?  Sure, your approach is technically correct -
but will it only result in further ST developer dropouts?  Aren't you holding
people to standards that Atari never fully documented in the first place?
-- 

Bob Rogers                    rogers@stpaul.ncr.com  or  rogers@pnet51.cts.com
NCR Comten, St. Paul, MN      GEnie: R.C.ROGERS

root@yale.UUCP (Celray Stalk) (04/04/89)

In article <1423@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
>Quite a few things in TOS are documented and have no useful function.
>That does not mean that programmers can or should have carte blanche to
>use these features.  Nor should anyone assume that the useless features
>will retain the same behavior in future TOS revisions.  It is
>unfortunate that the BETA TOS developer documentation was unclear on the
>lack of usefulness of the shel_put() and shel_get() AES calls, but that
>oversight will be corrected in the final release notes.
> 
>  Don't do illegal stuff with your software, please.  We are no longer
>constrained to strict software compatibility in future TOS revisions,
>and I, for one, intend to take advantage of that fact.  This means that
>I will be implementing enhancements which will almost certainly break
>software that either a) didn't follow the rules in the first place, or
>b) was built on bad assumptions about the internal workings of TOS.

Thank you, Ken, for the information you have been giving everyone on
the net.  I'd only like to point out that without decent
documentation, it's a little hard for software developers to even know
what the rules are.  It used to be that "illegal" was synonymous with
"undocumented"; however, your note suggests that even this is an
oversimplification, and "documented but useless" also implies
"illegal" and "likely to change in future releases of TOS".  I welcome
well-thought-out enhancements to TOS---they will make the ST's more
useful to everyone.  But the long-overdue "official" TOS documentation
is also important.  I hope Atari is making a renewed effort to finally
get that out the door.
==================================================
| Michael Fischer                                |
|    Arpanet:    <fischer-michael@cs.yale.edu>   |
|    Bitnet:     <fischer-michael@yalecs.bitnet> |
|    UUCP:       <fischer-michael@yale.UUCP>     |
==================================================