10.1 Three important programming rules

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

Programming guidelines

Style guidelines