Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!yale!root From: root@yale.UUCP (Root Of All Evil) Newsgroups: comp.sys.atari.st Subject: Re: ROM disassembly for TOS 1.4 Message-ID: <71359@yale-celray.yale.UUCP> Date: 1 Sep 89 14:18:19 GMT References: <9401@chinet.chi.il.us> <1666@atari.UUCP> Reply-To: fischer-michael@CS.YALE.EDU (Michael Fischer) Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Lines: 56 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: | | Bitnet: | | UUCP: | ==================================================