As the TOS operating system is relatively cleanly structured in several layers, all programmers should keep the following three rules at the back of their mind when creating an application:
Never intermix calls from different operating system
layers for one task! Example: In GEM programs the mouse and
keyboard are interrogated via AES, and not perhaps via the BIOS.
Disregarding this rule can lead to conflicts between the various
layers.
Never start with any unsafe assumptions about internal
coherence between the individual layers. Example: A GEMDOS
drive can lie both on a BIOS as well as a MetaDOS device. The mouse
normally hangs on the keyoboard chip, but it does not have to (with
new hardware, keyboard interfaces etc.)
Always use the highest possible operating system level
for a task. Example: Though the language to be used could be
obtained from the operating system header, it is better to use the
_AKP cookie or the function appl_getinfo for this.
Beyond this many further programming rules exist, which ought to be well-known but which are not heeded unfortunately by all applications. Some examples:
Only allocate as much memory as absolutely necessary, so that
in a multitasking environment other processes too can be launched or
work sensibly
Entry to the supervisor-mode should be avoided as much
as possible, as this is actually intended only for the operating
system, and in many environments no task-switching takes place
when a process is in this mode
Never write directly to screen memory, but always fall back to
the relevant GEM functions (AES, VDI)
Never access memory that does not belong to that particular
program, or has been made accessible to it, since this will give rise
to an exception on systems with memory protection; also, memory should
always be allocated in such a way that other processes should
preferably not be able to access the same block