Ein Thema, das von der allgemeinen Sprachbeschreibung nicht abgedeckt wird, ist die Frage nach der Laufzeit-Umgebung, in der der Programmcode konkret ausgeführt wird. Der Begriff des Programms als in sich abgeschlossener Einheit mit definiertem Einstiegspunkt, Ablauf und letztendlicher Termination wird in Oberon ja gar nicht angesprochen oder vorausgesetzt. Die Antworten können daher unterschiedlich ausfallen.
Das Züricher Oberon-System beispielsweise ist bzw. emuliert ein Ein-Benutzer-Betriebssystem, das keine separaten Prozesse kennt, sondern neue Module einfach zur Laufzeit in den einen Adreßraum hinzulädt und initialisiert [Wirth92]. Nach dem Laden sind bestimmte, commands genannte Prozeduren von der Benutzeroberfläche aus erreichbar und erfüllen so die Rolle, die dem herkömmlichen Programmbegriff vielleicht am nächsten kommt.
Demgegenüber kommt das Ulmer System ohne eine residente Umgebung aus. Übersetzte Module werden wie normale Programme in anderen Sprachen zusammen mit den benötigten Bibliotheken zu einer ausführbaren Datei (executable image) gebunden und können im gastgebenden Betriebssystem (etwa UNIX) als eigener Prozeß gestartet werden. Ein solcher Prozeß könnte sich wie das Züricher System verhalten und über commands und eine grafische Benutzeroberfläche mit dem Anwender kommunizieren, kann aber genausogut eine einzelne Aufgabe erledigen und danach terminieren, oder er bleibt als ein neuer Netzwerkdienst im Hintergrund und wartet auf Aufträge.
Damit auch hier kein ausgewiesenes Hauptmodul erforderlich ist, werden zum Programmstart einfach alle anfangs bekannten Module (genauer: eine beim Binden festgelegte Menge von Modulen) nacheinander initialisiert, wobei in bezug auf die Reihenfolge selbstverständlich die Importhierarchie eingehalten wird. Nach diesen Initialisierungen ist das Programm bereits beendet, es sei denn, neue Tasks sind entstanden und noch aktiv.
Innerhalb eines einzigen UNIX-Prozesses können selbstverständlich mehrere Oberon-Tasks ablaufen, und je nach Implementierung ist auch dynamisches Nachladen von Modulen möglich. Insofern verbindet das Ulmer System die Möglichkeiten einer Oberon-typischen mit einer an eigenständigen Programmen orientierten Sichtweise, die beim Einsatz als "Allzweck"-Programmierumgebung sicherlich in vielen Fällen angemessen ist.