amigaos-exec

Kontext 1985: warum AmigaOS auffiel

Mitte der 1980er war grafische Oberfläche allein noch kein Alleinstellungsmerkmal mehr. Interessant wurde es dort, wo ein Heimcomputer mehrere Dinge gleichzeitig konnte, ohne dass das gesamte System dabei auseinanderfiel. Genau dort fiel der Amiga auf: Grafik, Audio, Mausoberfläche und gleichzeitig echtes präemptives Multitasking auf einer Maschine, die preislich nicht im Workstation-Bereich lag.

Das Entscheidende ist aber: Dieses Multitasking war nicht nur ein Werbebegriff. Es war systemisch im Kern verankert. Exec verwaltete Tasks, Prioritäten, Ports, Messages und Signals so, dass mehrere Komponenten des Systems gleichzeitig aktiv sein konnten, ohne auf kooperatives Wohlverhalten aller Programme angewiesen zu sein. Das war 1985 im Heimcomputerbereich kein Normalzustand.

Gleichzeitig war das System nicht monolithisch im Sinn eines alles verschlingenden Kernels. AmigaOS war früh klar geschichtet: Exec als Kern, darüber Libraries und Systemdienste, Intuition für die GUI, AmigaDOS für Shell, Dateisysteme und Dateinamenraum. Wer diese Schichten nicht trennt, beschreibt am Ende alles unsauber.

„Der eigentliche Fortschritt war nicht die Oberfläche. Er war die Architektur darunter.“

Exec: was der Kernelkern wirklich macht

Exec ist der eigentliche Kern des Systems. Nicht „das ganze OS“, sondern der Teil, der die fundamentalen Mechanismen bereitstellt: Taskverwaltung, Scheduling, Signale, Message Ports, Interrupts, Speicherallokation und das Öffnen bzw. Schließen von Libraries und Devices. Man kann Exec als kleinen Kernelkern bezeichnen. Nicht deshalb, weil später das Wort „Mikrokernel“ modern wurde, sondern weil seine Aufgabe tatsächlich auf diese Grundmechanismen konzentriert ist.

Exec organisiert viele seiner internen Strukturen als verkettete Listen. Das ist kein Zufall und keine Eleganzübung. Es ist effizient, einfach nachvollziehbar und auf einer 68000-Maschine mit knappen Ressourcen sinnvoll. Ready-Listen, Waiting-Listen, Ports, Nodes – die gesamte Systemlogik ist stark listenorientiert.

Das Entscheidende an Exec ist nicht, dass es „viel“ macht. Es macht im Gegenteil relativ wenig – aber genau die richtigen Dinge. Alles, was darüber liegt, kann sich auf diese Grundmechanismen verlassen. Das ist der Grund, warum das System trotz begrenzter Hardware so lebendig wirkte.

Task-Level und Interrupt-Level

Gerade weil Exec Interrupts im Kern mitführt, muss man Task-Kontext und Interrupt-Kontext sauber trennen. Ein normaler Task läuft schedulierbar im üblichen Exec-Ablauf. Ein Interrupt dagegen unterbricht diesen Ablauf auf Hardware-Ereignisse hin und läuft nicht als gewöhnlicher DOS- oder Shell-Kontext. Auf Interrupt-Level gelten andere Regeln: kurz bleiben, keine unnötigen Seiteneffekte, keine DOS-Logik hineinziehen, keine bequemen Annahmen über blockierende Aufrufe machen.

Genau das ist beim Amiga mit seinen Level-1-bis-7-Interrupts und den Custom-Chips praktisch relevant. Die Architektur ist nicht deshalb interessant, weil sie „Interrupts auch kann“, sondern weil sie sauber zeigt, dass asynchrone Hardware-Ereignisse und schedulierbare Tasks zwei verschiedene Ebenen sind. Wer diese Ebenen vermischt, macht aus einem lesbaren System sehr schnell ein unlesbares.

Tasks, Scheduling und Prioritäten

Exec arbeitet mit Tasks, nicht im modernen Sinn mit stark isolierten Prozessen. Speicherschutz im heutigen Sinn gibt es nicht. Das bedeutet: Der Scheduler kann elegant und schnell sein, aber ein fehlerhaftes Programm kann weiterhin das ganze System beschädigen. Das ist kein Widerspruch, sondern die reale Form dieses Systems.

Der Scheduler ist präemptiv. Ein laufender Task muss die CPU nicht freiwillig abgeben; Exec kann umschalten, sobald die Bedingungen dafür vorliegen. Dazu kommen Prioritäten. Ein Task mit höherer Priorität verdrängt niedrigere, sofern er lauffähig ist. Das ist praktisch, aber auch gefährlich: Ein schlecht geschriebener Task mit zu hoher Priorität kann ein System effektiv ausbremsen.

Genau hier liegt einer der charakteristischen Züge des Amiga: technisch elegant, aber nicht paternalistisch. Das System hilft, aber es schützt nicht gegen jeden Fehler. Das ist leistungsfähig, solange die Beteiligten wissen, was sie tun.

Signals, Message Ports und Messages

Einer der stärksten Teile von Exec ist die Interprozess-Kommunikation. Nicht im Sinn schwerer, abstrakter Frameworks, sondern direkt und effizient: Ein Task kann auf Signale warten; Messages können über Message Ports zwischen Tasks verschickt werden. Das System bleibt dabei asynchron und klar.

Signals

Jeder Task hat eine Signalmaske. Signale sind Bitmarkierungen, auf die ein Task mit Wait() warten kann. Sie sind die leichtgewichtigste Form der Synchronisation: „Es ist etwas passiert, mach weiter.“ Mehr nicht. Gerade deshalb sind sie nützlich.

Message Ports

Ein Message Port ist ein Zielpunkt für Nachrichten. Ein Task besitzt typischerweise einen Port oder mehrere Ports; andere Tasks können Messages dorthin schicken. Intern hängen an einem Port Listen von Messages. Ein Port ist also kein bloßer Handle-Wert, sondern ein realer Knotenpunkt im Exec-Modell.

Messages

Messages sind Datenstrukturen mit Header und Nutzdaten, die an Ports geschickt werden. Das Grundprinzip ist pointerbasiert: Es werden nicht zwangsläufig große Datenblöcke kopiert, sondern Strukturen übergeben. Das ist schnell, setzt aber saubere Besitz- und Lebensdauerlogik voraus.

Dieses Modell ist bemerkenswert, weil es zugleich einfach und systemweit brauchbar ist. Es ist keine Sonderlösung für irgendeine GUI-Schicht, sondern ein Grundbaustein. Genau deshalb taucht es auch später in der DOS-Schicht wieder auf – dort allerdings in spezialisierter Form über DOS-Packets und Handler.

Libraries, Devices und Systemschichtung

AmigaOS ist nicht nur ein Kernel mit ein paar Syscalls. Es ist ein System aus Libraries und Devices, die bei Bedarf geöffnet werden. exec.library ist die Basis, darüber liegen weitere Libraries wie intuition.library, graphics.library oder dos.library. Dieser Aufbau ist ein Kernmerkmal des Systems.

Eine Library wird nicht einfach „angenommen“, sondern explizit geöffnet. Das hat praktische Konsequenzen: Versionen können geprüft werden, der Aufrufer weiß, worauf er sich stützt, und die Schichtung bleibt sichtbar. Das ist nüchterner als viele spätere Systeme, die zu viel implizit machen.

• exec.library: Kernmechanismen – Tasks, Ports, Messages, Signals, Interrupts, Speicher.
• intuition.library: Fenster, Menüs, Gadgets, GUI-Interaktion.
• graphics.library: Bildschirme, Bitmaps, Drawing-Primitiven.
• dos.library: Shell, Dateizugriff, Dateinamenraum, Handler-Kommunikation, Prozesse, Redirection, Script-Ausführung.

Wichtig ist die Trennung zwischen Exec Devices und AmigaDOS-Devices. Ein Exec-Device ist die gerätenahe Seite, etwa trackdisk.device oder serial.device. Ein AmigaDOS-Device ist die DOS-Namensraumseite wie DF0:, SER: oder CON:. Dazwischen sitzt typischerweise ein Handler oder Dateisystem-Handler. Wer diese Ebenen vermischt, beschreibt das System falsch.

Genauso wichtig ist die Praxisregel der Paarung: OpenLibrary() und CloseLibrary() gehören zusammen. Eine Library explizit zu öffnen ist nur die halbe Wahrheit; sie später sauber wieder zu schließen gehört zum selben disziplinierten Modell. Fehlende CloseLibrary()-Aufrufe waren keine theoretische Schönheitsfrage, sondern echte Quelle für schleichende Probleme, Inkonsistenzen und unaufgeräumte Zustände in langlebiger Software.

TRIPOS, BCPL und die Herkunft von AmigaDOS

Der eigentliche DOS-Teil des frühen AmigaOS kam nicht aus Exec herausgewachsen, sondern aus einer anderen Herkunftslinie: TRIPOS und BCPL. Das ist wichtig, weil viele Eigenheiten des frühen AmigaDOS genau daraus stammen.

TRIPOS war ein portables Betriebssystem aus dem akademischen Umfeld, später von MetaComCo auf den 68000 gebracht. Commodore nutzte diesen Unterbau für das frühe AmigaDOS. Deshalb war AmigaDOS 1.x stark BCPL-geprägt. Das merkt man nicht nur historisch, sondern ganz konkret an Begriffen und Datentypen.

BPTR und BSTR

BCPL arbeitet mit anderen Pointer-Konventionen als C. Ein klassisches Beispiel ist der BPTR: kein normaler Bytepointer, sondern ein wortadressierter Pointer im BCPL-Stil. Praktisch heißt das: Werte sind gegenüber normalen Adressen verschoben/skaliert, und man kann sie nicht einfach wie normale C-Pointer behandeln. Dasselbe gilt für BSTR, also längencodierte Strings mit anderer Konvention als nullterminierte C-Strings.

Genau diese BCPL-Erbschaft war einer der Gründe, warum frühes AmigaDOS aus C- oder Assembler-Sicht oft sperriger wirkte als Exec. Nicht weil die DOS-Ideen schlecht gewesen wären, sondern weil die Datendarstellung aus einer anderen Welt stammte.

Wer frühe AmigaDOS-APIs verstehen will, muss diese Herkunft mitdenken. Sonst wirkt manches unnötig exotisch, obwohl es historisch einfach konsequent ist.

dos.library und der DOS-Namensraum

dos.library ist die Schicht, die aus roher Exec-Mechanik einen benutzbaren Dateisystem- und Shell-Betrieb macht. Hier liegen Dateinamenraum, Shell-Kommandoausführung, Handler-Ansprache, Locks, File Handles, Redirection, Script-Logik und Prozessdetails. Das ist der eigentliche AmigaDOS-Kern.

Der Namensraum von AmigaDOS ist kein Unix-Namensraum und auch kein MS-DOS-Laufwerksmodell. Namen wie DF0:, DH0:, RAM:, CON:, SER:, PIPE: oder NIL: sind logische DOS-Gerätenamen im selben Namensraum. Dazu kommen Assigns wie SYS:, C:, S:, L: oder LIBS:. Dieser Namensraum ist flexibler als ein starres Laufwerksbuchstabenmodell, aber er verlangt, dass man die Begriffe korrekt trennt.

• Volume / Device Name: etwa DH0: oder DF0: – Ausgangspunkt eines Pfads.
• Assign: logischer Alias auf ein Verzeichnis oder mehrere Verzeichnisse, z. B. LIBS:.
• Handler-basierte DOS-Ziele: CON:, SER:, PIPE:, NIL: – keine „Dateien“, aber im DOS-Namensraum wie solche benutzbar.

Das wirkt zuerst ungewohnt, ist aber technisch sauber: Alles, was sich wie ein DOS-Endpunkt verhält, lebt im gleichen Namensraum und kann über die DOS-Schicht angesprochen werden. Genau das macht Redirection und flexible Geräteansprache so elegant.

Die DOS-Schicht selbst – mit Locks, File Handles, Assigns, Handlern, DOS-Packets, RUN und EXECUTE – steht auf der Schwesterseite amiga-dos.htm im Detail. Hier geht es bewusst um die größere Schichtung mit Exec darunter.

Handler, Devices und DOS-Packets

Einer der wichtigsten Punkte überhaupt: AmigaDOS arbeitet gegenüber Dateisystemen und DOS-Geräten nicht direkt mit rohen Exec-Devices, sondern mit Handlern. Ein Handler ist ein Prozess, der eine standardisierte Menge an DOS-Anfragen verarbeitet.

Das bedeutet konkret: Wenn ein Programm Open("DF0:datei", ...) oder Read(fh, ...) aufruft, führt dos.library nicht selbst die gesamte Dateisystemarbeit aus. Stattdessen werden Anfragen an den zuständigen Handler geschickt – typischerweise per Message Port und in Form von DOS-Packets. Der Handler übersetzt diese DOS-Anfrage in die passenden low-level Operationen, oft unter Nutzung eines Exec-Devices wie trackdisk.device.

DOS-Packets

DOS-Packets sind spezialisierte Message-Strukturen für DOS- und Dateisystemoperationen. Man kann sie als Exec-Style-Messages mit zusätzlicher Parameterstruktur verstehen. Für normale Programme ist wichtig: Man arbeitet meist über dos.library und nicht direkt mit selbstgebauten DOS-Packets. Für Handler-Autoren ist dieses Modell jedoch zentral.

Das ist eine saubere Entkopplung. dos.library muss nicht jedes Dateisystem oder jedes Sondergerät im Detail kennen. Es reicht, dass die Handler die Paketkonventionen verstehen.

Shell, CLI und das Process-Modell

Die Shell ist nicht bloß ein Fenster mit Prompt. Sie ist ein DOS-Prozess. Genau hier wird der Unterschied zwischen Exec und AmigaDOS besonders greifbar.

Ein DOS-Process ist mehr als ein Exec-Task. Offiziell kann man ihn als Kombination aus Exec task structure, Exec message port und AmigaDOS process value sehen. Der interne Prozessidentifikator im DOS-Kontext ist dabei der Pointer auf den Exec-Message-Port pr_MessagePort, von dem aus der zugehörige Exec-Task ermittelt werden kann.

Das ist entscheidend, weil Shell und Kommandoausführung genau auf dieser Ebene leben. Eine Shell liest Eingaben, wertet Redirection aus, sucht Kommandos im Suchpfad, startet externe Programme und Scripts und verwaltet den Kontext – aktuelles Verzeichnis, offene Streams, Prompt, Return Codes und ähnliche Dinge. Das ist DOS-Logik, nicht Exec-Logik.

CLI, Shell, NewShell, NewCLI

Es können mehrere Shell-Prozesse gleichzeitig laufen. Sie werden intern nummeriert. NEWSHELL bzw. NEWCLI starten einen neuen Shell-Prozess. Das ist nicht bloß ein neues Fenster, sondern tatsächlich ein weiterer DOS-Prozess mit eigenem Kontext.

Genau deshalb lässt sich AmigaDOS auch gut skripten und mehrfach parallel benutzen. Jede Shell ist ihr eigener DOS-Kontext, nicht nur eine andere Darstellung desselben globalen Zustands.

Assigns, Locks und File Handles

Assigns

Ein Assign ist ein logischer Name, der auf ein Verzeichnis – oder sogar auf mehrere Verzeichnisse – zeigt. LIBS:, C:, S: oder L: sind die klassischen Beispiele. Dadurch muss Software nicht wissen, auf welchem konkreten Volume sich eine Ressource befindet; sie fragt einfach LIBS: oder C: ab.

Besonders stark ist, dass Assigns nicht auf genau ein Ziel festgelegt sein müssen. Mit passenden Optionen kann ein Assign um weitere Verzeichnisse ergänzt werden. Das System durchsucht dann die Assign-Liste in Reihenfolge. Das ist eine überraschend flexible Lösung für ein solches System.

Locks

Ein Lock ist in AmigaDOS nicht nur „gesperrt“ im umgangssprachlichen Sinn, sondern eine konkrete Struktur für Zugriff und Referenzierung. Locks werden verwendet, um Objekte eindeutig zu referenzieren und konkurrierende Zugriffe zu kontrollieren. Wesentlich sind dabei Shared Locks und Exclusive Locks.

• Shared Lock: für lesenden Zugriff; mehrere gleichzeitig möglich.
• Exclusive Lock: für schreibenden Zugriff; Konflikte mit anderen Locks werden verhindert.

Das ist wichtig, weil viele DOS-Funktionen nicht nur mit Pfadstrings arbeiten, sondern intern mit Locks weitergehen. Ein Lock ist damit sowohl Schutzmechanismus als auch Navigationshilfe im Dateisystem.

File Handles

Ein File Handle ist der laufende Zugriffskanal auf eine geöffnete Datei oder einen streamartigen DOS-Endpunkt. Für das aufrufende Programm ist das die konkrete Arbeitsoberfläche: lesen, schreiben, seeken, schließen. Ein File Handle ist also der operative Gegenpart zum Lock. Der Lock referenziert und schützt, der File Handle arbeitet laufend mit dem geöffneten Objekt.

Wichtig ist, dass File Handles auf weit mehr als bloße Plattendateien zeigen können. CON:, SER:, PIPE:, NIL: – all das lässt sich im DOS-Sinn wie ein Datei-Endpunkt öffnen und behandeln. Genau daraus entstehen die flexible Redirection und die Shell-Stärke des Systems.

Pipes, Redirection, Execute und Run

Redirection

Redirection gehört zur Shell-Schicht. Mit < und > kann Eingabe oder Ausgabe auf Dateien oder DOS-Geräte umgelenkt werden. Die Shell analysiert die Kommandozeile und sorgt dafür, dass die gestarteten Programme andere Ein- oder Ausgabeströme sehen als das eigentliche Konsolenfenster.

PIPE:

PIPE: ist ein handlerbasierter Kommunikationskanal für gepufferte I/O-Kommunikation zwischen Programmen. Technisch interessant daran ist, dass er wie ein DOS-Endpunkt im Namensraum erscheint. Für Programme, die sequentielle Ein-/Ausgabe erwarten, kann PIPE:name wie eine Datei wirken, obwohl dahinter ein interprozessualer Puffermechanismus steckt.

Das zeigt exemplarisch, wie stark die DOS-Schicht des Amiga ist: Ein Kommunikationsmechanismus wird nicht als exotischer Sonderfall nebenher gebaut, sondern sauber in denselben Namensraum eingebunden wie Dateien und Geräte.

Execute

Execute() beziehungsweise das Shell-Kommando EXECUTE gehören zur DOS-/Shell-Schicht. Execute() führt eine Shell-Kommandozeile aus. Wichtig: Die Funktion kehrt grundsätzlich erst zurück, wenn die angeforderte Kommandoausführung abgeschlossen ist. Sie ist also nicht die primitive „starte im Hintergrund und vergiss es“-Variante.

Zusätzlich kann Execute() mit passenden File Handles so benutzt werden, dass ein neuer interaktiver Shell-Kontext entsteht. Genau deshalb gehört Execute() in eine Seite über AmigaDOS und nicht in eine Seite über nacktes Exec.

Run

RUN ist die Shell-seitige Antwort auf „starte im Hintergrund“. Das Kommando lädt und startet ein Programm beziehungsweise eine Shell-Aktivität so, dass der Prompt zurückkehrt und die aktuelle Shell weiter bedient werden kann. Das ist keine neue Scheduling-Theorie – sondern konkrete DOS-Prozesslogik.

Praktisch wichtig ist dabei: Die gestartete Aktivität bleibt mit ihrem Ursprungskontext verbunden, insbesondere was Ein-/Ausgabe betrifft, wenn man nicht bewusst auf NIL: oder andere Ziele umlenkt. Genau deshalb kann man eine Shell nicht beliebig schließen, solange von ihr gestartete Hintergrundprozesse noch an ihren Streams hängen.

Guru Alert präzise erklärt

Die berühmte Guru Meditation ist weder bloß Kult noch bloß ein „Absturzbildschirm“. Präziser ist: Es handelt sich um einen Alert-/Fehlermechanismus des Systems. Die ausgegebene Zahl ist strukturiert und kodiert Informationen über Fehlerklasse und betroffene Komponente.

Entscheidend ist dabei der nüchterne Blick: Ein Guru Alert ist keine philosophische Botschaft und auch nicht automatisch ein Debugger im modernen Sinn. Er ist ein sichtbarer, formatierter Systemalarm. In manchen Fällen ist ein Fehler als recoverable gedacht, in anderen ist er fatal. Das hängt von der Alert-Klasse ab.

Ein greifbares Beispiel

Nimmt man beispielhaft einen Alert wie 00000003 00000000, dann ist das nicht „irgendeine Zahl mit Kultfaktor“, sondern ein kodierter Fehlerwert plus ein zweites Longword als Zusatzkontext. Vereinfacht gelesen trägt der erste Teil die eigentliche Alert-Information – also Klasse und Fehlerbereich –, während der zweite Teil zusätzlichen Kontext liefern kann, je nach Fehlerfall etwa als weiterer Wert oder Adressbezug.

Der entscheidende Punkt ist nicht, jede Zahl auswendig zu kennen, sondern das Prinzip zu verstehen: Ein Guru Alert war als strukturierte Diagnose gedacht. Genau deshalb ist er technisch interessanter als sein späterer Ruf als bloßer Absturzname.

Dass der Guru Alert bis heute so stark erinnert wird, liegt nicht nur am Namen. Es liegt daran, dass das System an dieser Stelle sichtbar ehrlich wird: Es verdeckt den schweren Fehler nicht mit allgemeiner Freundlichkeit, sondern zeigt an, dass etwas grundsätzlich schiefgelaufen ist.

Im klassischen Amiga-Kontext darf man dabei eines nicht vergessen: Ohne Speicherschutz ist ein schwerer Programmfehler eben nicht sauber auf den fehlbaren Task beschränkt. Gerade deshalb sind Alerts auf dieser Ebene systemisch relevant.

„Ein Guru Alert ist keine Legende. Er ist die formalisierte Aussage, dass die Sache an einer fundamentalen Stelle entgleist ist.“

Was daran bis heute bemerkenswert ist

Bemerkenswert ist nicht nur, dass der Amiga früh präemptives Multitasking hatte. Bemerkenswert ist die Kombination aus technischer Eleganz und praktischer Lesbarkeit. Exec unten, DOS darüber, Handler als vermittelnde Prozesse, Libraries als explizite Systemschicht, Shell und Dateinamenraum als benutzbarer Überbau – das ist nicht zufällig gewachsenes Chaos, sondern als Struktur erkennbar.

Ebenso bemerkenswert ist, dass genau diese Eleganz nicht mit moderner Schutzarchitektur verwechselt werden darf. Das System ist offen, schnell, direkt – und dadurch verwundbar. Es verlangt Können. In diesem Sinn ist AmigaOS kein bequemes System, sondern ein ehrliches.

Für mich liegt genau darin der bleibende Wert: Man kann an AmigaOS / Exec / AmigaDOS noch heute sauber studieren, was eine gute Schichtung ist, wie Interprozess-Kommunikation sinnvoll klein gehalten werden kann und warum Shell-/Dateisystemlogik als eigene Ebene über dem Kernel existieren sollte.

„AmigaOS war stark, wo es geschichtet war – nicht wo man alles in einen einzigen Begriff warf.“

Die DOS-Schicht im Detail steht auf amiga-dos.htm. Die konkreten Systeme, an denen diese Architektur im Alltag erfahrbar wurde, stehen auf hardware.htm und amiga4000t.htm.

Querverweise im SSLXY-Archiv

Diese Seite gehört zu den Amiga-Architekturthemen im sslxy-Bereich. Sie ergänzt die DOS-Seite, die Chipsatz-Seite und die konkreten Geräteakten.

• Zur SSLXY-Hauptseite
• Zur Seite amiga-2000.htm
• Zur Seite amiga-dos.htm
• Zur Seite amiga-ocs-ecs-aga.htm
• Zur Seite amiga4000t.htm
• Zur Hardware-Übersicht
• Zur Systems-Seite