Further additions, corrections, and suggestions are welcome. This text concerns the Oberon system, while the other two are about general topics and about Oberon the programming language. The underlying dynamic model is extremely simple. There exists a single process acting as a common carrier of multiple tasks. This process repetitively interprets commands, which are the official entities of execution in Oberon.
Commands are atomic actions operating on the global state of the system.
Unlike customary interactive programs, they rigorously avoid direct dialogs with the system user. The result is a system that provides efficiency and reliability rather than offering inflated size, which dramatically increases the probability of bugs and flaws. What is most astonishing about Oberon is its smallness. From our vision and from examples like the one in Figure 1 it followed immediately that System 3 needs to be settled one important step beyond the ordinary state of object-oriented programming because it needs to be able to manage hundreds or even thousands of persistent objects and components that can appear in extensive variety, including at least character patterns, formulae, all kinds of figures, pictures, gadgets and widgets. What was obviously needed is a central object management and some concept like object library.