AmigaOS Programming Philosophy

The single most important thing to internalise before writing AmigaOS software: stay upwards-compatible and never hack undocumented or private areas. This is stated in the strongest possible terms by Heinz Wrobel (Amiga Technologies) on the Developer CD, because Amiga Technologies was actively moving the OS to PowerPC and restructuring exec.library / Intuition internals. Code that pokes private fields, bangs hardware registers, or relies on empirical behaviour "will definitely make your SW and probably more crash on a future Amiga."

"Amiga Technologies will no longer tolerate knowingly any violation of established and specified programming practices. Hacks, fiddling with undocumented features, empirical programming, and the like will definitely make your SW and probably more crash on a future Amiga. YOU HAVE BEEN WARNED!"

Core principles

  • Use the OS API, not the hardware. If there is an OS function to do something or access a structure, use it. If there isn't one, treat that absence as an indicator that you should not be doing it. "Banging the HW usually only shows incompetence." Use graphics.library instead of OCS/ECS/AGA registers; use timer.device, parallel.device, serial.device instead of poking the CIAs.
  • Treat private structures as black boxes. struct ExecBase, IntuitionBase internals, layer lists, etc. changed before (IntuitionBase in 1991) and will change again on PowerPC. Do not read or write private fields even when headers label them "readable" — e.g. SysBase->ThisTask was redeclared private as of 1 January 1996; use FindTask(NULL) instead.
  • Stay at the task/process level. Avoid interrupt and trap/exception handling where possible. Interrupt handling is expected to change substantially.
  • Synchronise with semaphores, not with Forbid()/Disable(). Using Forbid() "to speed up things" is explicitly called out as a mark of incompetence. Do not rely on atomicity of single CPU instructions (a single instruction may no longer be atomic on PowerPC).
  • A public blacklist exists. Amiga Technologies planned a public list of incompatible / badly-behaved software, and the CD ships with the seed of one (BadSoftware). Bugs were to be reported to bugs@amiga.de.

Where the rules live

The authoritative rule documents on this CD are under DevInfo/:

Path Covers
DevInfo/README.FIRST The warning above; orientation.
DevInfo/Style/CodingStandards C coding style + source-management rules.
DevInfo/Exec_and_PowerPC/FutureOS The PowerPC / future-OS restrictions (private fields, forbidden exec calls).
DevInfo/DeviceDevelopment/CommandHandling, NewStyleCommands Device-driver command-set rules and the "new style device" standard.
DevInfo/Intuition/Hints, LockLayer, ObtainGIRPort Layer-locking deadlock rules for gadget/datatype authors.
DevInfo/BlackList/BadSoftware Named incompatible software.
DevInfo/RequiredReading Annotated bibliography of Amiga programming books (SW/HW/HISTORIC).

Adhering to these is described as "vital for future enhancements to the OS and for portability to new CPU architectures." Treat all of it as load-bearing when writing or reviewing Amiga code.

See Also

Sources: Heinz Wrobel, Amiga Technologies, DevInfo texts (1996). Raw: raw/conventions/devinfo-philosophy.md Updated: 2026-08-04