🚀 go-pugleaf

In article <1666@atari.UUCP> towns@atari.UUCP (John Townsend) writes:
>in article <9401@chinet.chi.il.us>, saj@chinet.chi.il.us (Stephen Jacobs) says:
>> 
>> One of the more useful tools in programming the ST is the commented ROM
>> disassembly in the Abacus ST Internals book (English translation of the
>> corresponding Data Becker book, I think, but I'm usually wrong).  
>
>I disagree completely. People should use the documented OS calls. They 
>shouldn't fumble around inside the Operating System looking for calls and 
>data structures that weren't intended for their use.
>
> ...
>
>Anyway, there's my position on disassembled versions of TOS.

Things just aren't so simple.  Yes, I agree that people should follow the
rules and should use the documented OS calls.  The problems come when:
(1) The documentation is inadequate to determine what the "rules" are.
(2) The OS calls are inadequate to accomplish the task at hand.

The TOS documentation is still far from adequate.  Developers still do
not have the promised TOS 1.4 release notes, and many important
aspects of the system are as yet not properly documented, even in the
developers kit.  By looking in commented source code, one can often
determine what the intended rules are.  Without the source code, one
is forced to resort to trial and error to find something that happens
to work (which may well violate the unstated rules and not work in
future releases of the OS).

In the cases where the OS calls are inadequate, the alternative to
"fumbling around inside the Operating System" is often to not write
the application at all.  If people religiously stuck by the rules, we
wouldn't have reset-proof ramdisks (what is the documented OS call to
allocate a block of memory that survives a warm boot?), nor would people
have been able to survive the bugs of TOS 1.0 so well for so many years,
since the TSR patches that we can throw away with TOS 1.4 couldn't have
been written in the first place!

Of course, developers should try to write their programs in a way that
makes them as widely useable across different platforms as possible,
but that doesn't imply that if a program will not be usable on all
platforms, now and in the future, that it shouldn't be written.  Many
programs require special features or equipment not available on all
machines, e.g. color screens, hard disks, more than 512K of memory,
scanners, printers, etc.  Such programs should make clear what their
requirements are, including any dependencies on particular releases of
the operating system.  The support problems come when programs aren't
clear about their OS dependencies and customers aren't aware that
different versions of the OS exist.

==================================================
| Michael Fischer                                |
|    Arpanet:    <fischer-michael@cs.yale.edu>   |
|    Bitnet:     <fischer-michael@yalecs.bitnet> |
|    UUCP:       <fischer-michael@yale.UUCP>     |
==================================================