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