amigados

Einordnung: was AmigaDOS überhaupt ist

AmigaDOS ist nicht das gesamte Betriebssystem und auch nicht einfach nur die Shell. Es ist die DOS-Schicht von AmigaOS: also der Bereich, der Dateisystem-I/O, Pfadauflösung, Prozesse, Redirects, Kommandostart, Skripte und die Kommunikation mit Handlern organisiert. Diese Schicht sitzt nicht neben Exec, sondern baut auf Exec auf. Ohne Exec keine Tasks, keine Message Ports, keine Signals – und ohne diese Mechanismen kein AmigaDOS.

Praktisch heißt das: Wer Open(), Read(), Write(), Lock(), AssignLock(), Run oder Execute benutzt, arbeitet nicht direkt mit Gerätetreibern, sondern mit der DOS-Abstraktion. Die DOS-Schicht löst Namen auf, sucht den zuständigen Handler, übersetzt Funktionsaufrufe in Packets, sendet sie an den Zielprozess und liefert das Ergebnis zurück.

Das erklärt auch die eigentümliche Stärke des Systems: Der Namensraum ist flexibel, weil Geräte, Volumes, Verzeichnisse und Assigns unter derselben syntaktischen Oberfläche erscheinen. DF0:, RAM:, SYS:, C:, L:, CON: oder ein selbst definierter Assign wie WORK: sehen auf der Kommandozeile gleichartig aus – aber sie stehen intern für sehr verschiedene Dinge.

„AmigaDOS ist nicht das Fenster, in das man tippt. Es ist die Schicht, die dafür sorgt, dass ein Name überhaupt irgendwo sinnvoll ankommt.“

BCPL und TRIPOS-Herkunft

Wer AmigaDOS nur oberflächlich kennt, übersieht leicht, wie stark diese Schicht noch aus einer älteren Herkunft spricht. Ein Teil der eigentümlichen Begriffe und Datentypen ist kein Zufall, sondern direkte Folge der BCPL- und TRIPOS-Vorgeschichte. Genau dorther kommen die Dinge, die für moderne C-geprägte Systeme auf den ersten Blick merkwürdig wirken.

BCPL-Spuren, die wirklich relevant bleiben

Zwei Reste sind besonders sichtbar: BPTR und BSTR. Ein BPTR ist kein normaler Byte-Pointer, sondern ein auf Longword-Ebene kodierter Zeiger. Praktisch bedeutet das: Der gespeicherte Wert ist um zwei Bits nach rechts verschoben, weil BCPL mit wortadressierten Zeigern arbeitete. Ein BSTR ist eine BCPL-String-Struktur: Das erste Byte enthält die Länge, danach folgen die Zeichen. Für C-Code ist das unbequem, für die historische Herkunft aber völlig logisch.

Das ist nicht nur Kuriosität. Es erklärt, warum viele DOS-Strukturen und Autodocs an bestimmten Stellen anders wirken als normale C-APIs. Wer mit Seglists, Locks, Assign-Startups oder Mount-Parametern arbeitet, stößt auf diese Prägung immer wieder.

TRIPOS als gedanklicher Vorläufer

Auch der Aufbau des DOS-Bereichs selbst – Kommandointerpreter, Dateinamensraum, Prozessmodell, Redirects, logische Gerätenamen – steht in einer Linie mit TRIPOS. AmigaDOS wurde nicht aus dem Nichts entworfen, sondern übernahm einen Denkstil: Prozesse als klar getrennte Einheiten, Gerät- und Dateizugriffe über symbolische Namen, Shell als praktisches Frontend, DOS-Aufrufe als schmale Schnittstelle.

Genau dadurch wirkt AmigaDOS zugleich elegant und spröde. Elegant, weil die Grundideen klein und klar bleiben. Spröde, weil die Herkunft an manchen Stellen sichtbar bleibt und nicht glatt in eine rein C-zentrierte Welt übersetzt wurde.

dos.library als Kern der DOS-Schicht

Wenn Exec der Kernel-Kern ist, dann ist dos.library die zentrale Vermittlungsschicht für alles, was im AmigaOS nach Dateisystem, Pfad, Prozess oder Kommando aussieht. Das ist der Ort, an dem der Benutzer oder das Programm nicht mehr mit rohen Geräten spricht, sondern mit einem DOS-Modell: Dateien öffnen, Verzeichnisse wechseln, Prozesse starten, Pfade suchen, Assigns auflösen, Redirects anwenden.

Wichtig ist dabei die Rollenverteilung: dos.library erledigt vieles nicht selbst im Sinn einer monolithischen Implementierung. Sie verwaltet Zustände, übersetzt Aufrufe, löst Namen auf und kommuniziert mit anderen Prozessen. Der eigentliche Zugriff auf konkrete Streams, Dateisysteme und Pseudogeräte läuft oft über Handler.

Nur DOS-Prozesse dürfen DOS sauber aufrufen

Eine technische Nuance, die oft übersehen wird: Nicht jeder beliebige Exec-Task ist automatisch ein vollständiger DOS-Kontext. Viele DOS-Funktionen setzen voraus, dass der aufrufende Kontext ein AmigaDOS-Process ist – also ein Exec-Task mit den zusätzlichen DOS-Strukturen. Das ist kein Stilproblem, sondern eine strukturelle Bedingung.

Process-, CLI- und Shell-Modell

Einer der wichtigsten Punkte im AmigaDOS-Bereich ist die Trennung zwischen allgemeinem Exec-Task, DOS-Process und CLI-/Shell-Kontext. Ein DOS-Process ist nicht einfach nur ein Task mit einem anderen Namen, sondern ein Exec-Task mit zusätzlichen DOS-spezifischen Feldern. Dazu gehören unter anderem sein Message-Port, der DOS-Kontext, CurrentDir, Result-Codes und – im CLI-Fall – weitere Strukturen für die Kommandozeile.

Der interne Prozessbezug in der DOS-Welt hängt eng mit dem Exec-Message-Port zusammen. Das ist typisch Amiga: Auch hier keine schwere Prozess-ID-Verwaltung im späteren Unix-Sinn, sondern ein enger Bezug zwischen Prozess und Nachrichtenmechanik.

CLI ist nicht einfach nur „die Shell“

Historisch ist die CLI zunächst der Kommandozeilen-Kontext eines DOS-Prozesses. Die Shell ist die benutzerseitige Oberfläche dieses Kontexts. Praktisch sieht man das am Prompt, an Redirects, an den Startarten und an den Skriptmechanismen. Ein Shell-Fenster ist also nicht nur ein Textfenster, sondern ein DOS-Process mit eigenen Standard-Streams, eigenem CurrentDir, eigener CLI-Nummer und einer laufenden Kommandoumgebung.

Das erklärt auch, warum RUN, Execute, NewCLI oder NewShell nicht bloß kosmetische Varianten sind. Sie erzeugen unterschiedliche Startsituationen, vor allem im Hinblick auf Streams, Stack, CLI-Status und Eltern-Kind-Beziehungen innerhalb der DOS-Schicht.

Namensraum: Volumes, Devices, Assigns

Der AmigaDOS-Namensraum ist einer der stärksten Teile des Systems. Er wirkt auf den ersten Blick simpel, ist aber deutlich flexibler als viele zeitgenössische DOS-Modelle. Alles hängt an der Doppelpunktsyntax: NAME:. Entscheidend ist nicht die Schreibweise, sondern was der Name zur Laufzeit bedeutet.

• Volume-Namen: Benennen eingehängte Datenträger oder Dateisysteme, z. B. Workbench: oder DH0:.
• Device-/Handler-Namen: Benennen DOS-Geräte oder Pseudogeräte wie CON:, RAW:, NIL:, PIPE:, RAM:.
• Assigns: Logische Namen, die auf Verzeichnisse oder Listen von Verzeichnissen zeigen, z. B. C:, S:, L:, LIBS:, DEVS:.

Ein Assign ist dabei nicht bloß eine Abkürzung, sondern ein echter Teil der Pfadauflösung. Wenn C: auf ein Verzeichnis zeigt, dann verhält sich C:List für DOS wie ein sinnvoller, normaler Pfad. Genau dadurch gewinnt AmigaDOS seine praktische Beweglichkeit: Ressourcen können umgehängt, erweitert oder ersetzt werden, ohne die gesamte Pfadsymbolik des Systems zu verändern.

Besonders stark ist die Mehrfachzuweisung: Ein Assign kann auf mehrere Verzeichnisse zeigen. Damit entsteht ein Suchpfad innerhalb des DOS-Namensraums – kein bloßer Alias. Genau das macht die Standardstruktur mit C:, LIBS: oder DEVS: so nützlich.

Locks, File Handles und CurrentDir

Eines der Dinge, die man bei AmigaDOS sauber trennen muss, ist der Unterschied zwischen Lock und File Handle. Beides sind keine austauschbaren Begriffe. Ein Lock steht für eine gesicherte Referenz auf ein Dateisystemobjekt – meist ein Verzeichnis oder eine Datei im Kontext der Pfadauflösung. Ein File Handle steht für einen geöffneten I/O-Strom, also für die tatsächliche Nutzung einer Datei oder eines Geräts über Read/Write.

Lock

Ein Lock ist für DOS vor allem ein Navigations- und Referenzobjekt. CurrentDir arbeitet mit Locks. Wenn man das aktuelle Verzeichnis ändert, liefert DOS typischerweise den alten Lock zurück, damit der Aufrufer ihn später wiederherstellen oder freigeben kann. Das ist sauber, weil der Zustand explizit geführt wird und nicht in einer versteckten Prozessvariable verschwindet.

File Handle

Ein File Handle ist das Identifikationsobjekt für geöffnete Dateien oder DOS-Streams. Wer Open() aufruft, bekommt einen Handle. Dieser Handle wird dann an Read(), Write(), Seek(), Close() und verwandte Routinen übergeben. Praktisch ist das die Arbeitsebene des I/O.

CurrentDir als explizite Zustandsänderung

Das aktuelle Verzeichnis eines DOS-Prozesses ist nicht bloß ein kosmetischer Shell-Zustand. Es beeinflusst die Auflösung relativer Namen. Genau deshalb ist CurrentDir() so zentral: Es verändert den Pfadkontext des Prozesses und gibt den vorherigen Zustand als Lock zurück. Das ist nüchtern, präzise und typisch AmigaDOS.

Handler, Devices und Filesystems

Ein zentrales Merkmal von AmigaDOS ist, dass viele „Geräte“ im DOS-Sinn nicht bloß Hardwaregeräte sind, sondern Handler-Prozesse. Das bedeutet: Ein DOS-Name wie CON:, RAW:, PIPE:, RAM: oder ein Dateisystem-Zugriff auf ein Volume endet oft nicht in einem simplen Treiberaufruf, sondern in einer Packet-Kommunikation mit einem zuständigen Prozess.

Das ist konzeptionell sauber. DOS muss nicht jede Geräteklasse fest einbauen. Es spricht mit einem standardisierten Gegenüber. Dieses Gegenüber kann ein Dateisystem, ein Konsolenhandler, ein Pipe-Handler oder ein sonstiger Pseudogeräteprozess sein.

Warum das wichtig ist

Genau dadurch kann DOS Dinge wie CON: oder RAW: im selben Namensraum behandeln wie Datenträger. Für die Shell und für Skripte ist das enorm praktisch: Standard-Ein- und Ausgaben sind genauso umleitbar wie Dateizugriffe. Für den Benutzer sieht das schlicht aus. Intern steckt aber ein Prozessmodell dahinter.

Eine besonders interessante Nuance ist das Startverhalten von Handlern: Einige patchen ihren Task-Bezug so, dass spätere Zugriffe denselben laufenden Prozess wiederverwenden. Andere – klassisch etwa CON: – können bei weiteren Zugriffen neue Prozessinstanzen erzeugen, je nach Aufbau und Zweck.

DOS-Packets im Detail

Einer der entscheidenden technischen Punkte im AmigaDOS-Bereich ist die packet-basierte Kommunikation. DOS-Packets sind die standardisierte Form, in der DOS-Prozesse und Handler miteinander sprechen. Sie sitzen nicht außerhalb von Exec, sondern auf dessen Message-Passing-Mechanik auf. Das ist der eigentliche Grund, warum AmigaDOS intern so konsistent wirkt.

Wenn ein Programm etwa Open() oder Read() aufruft, kann dos.library daraus ein Packet machen, dieses an den zuständigen Handler senden und auf die Antwort warten. Das geschieht typischerweise synchron aus Sicht des Aufrufers, obwohl darunter Message-Ports und Signals arbeiten. Für asynchronere oder direktere Arbeit gibt es den Packet-Weg auch explizit.

Gedanklicher Aufbau eines DOS-Packets

Ein Packet trägt im Kern einen Typ – also die gewünschte Operation – und mehrere Argumentfelder. Welche Bedeutung diese Felder haben, hängt vom Packet-Typ ab. Genau diese Schlichtheit macht das Modell robust: Nicht jede Operation braucht eine eigene exotische Sonderstruktur. Ein Operationstyp plus Argumente reicht.

Warum das Modell stark ist

Das Packet-Modell trennt DOS-Funktion und konkrete Implementierung sauber. DOS sagt, was passieren soll. Der Handler entscheidet, wie das passiert. Das ist dieselbe Tugend, die man an vielen guten Systemen mag: kleine, wiederverwendbare Schnittstellen statt aufgedunsener Sonderfälle.

„AmigaDOS wirkt so geschlossen, weil es intern nicht auf viele Sonderwege setzt. Es setzt auf Packets.“

MountList und DOSDrivers

Geräte und Filesysteme fallen im AmigaDOS nicht magisch vom Himmel. Sie müssen beschrieben und DOS bekannt gemacht werden. Historisch geschah das über die MountList, später und praxisnäher über einzelne Dateien in DEVS:DOSDrivers. Die beiden Mechanismen sind eng verwandt: DOSDrivers sind im Grunde einzelne, getrennte Mount-Beschreibungen statt eines gemeinsamen großen Textbestands.

Genau hier sieht man wieder den DOS-Stil des Systems: Ein Gerät ist nicht zuerst ein GUI-Objekt oder eine Registry-Zeile, sondern eine textuell beschreibbare Struktur. Darin stehen Dinge wie Handler, FileSystem, Device, Unit, Priorität, Stackgröße, Startup-Wert und weitere Parameter. Wird der Eintrag aktiviert, kann DOS das Gerät einhängen oder den Handler starten.

MountList

Die klassische MountList ist eine ASCII-Textdatei mit Einträgen pro Gerät. Jeder Eintrag beschreibt, welcher Handler oder welches Filesystem verwendet wird und mit welchen Parametern das Ganze laufen soll. Das ist historisch sauber und für Administratoren gut lesbar, aber mit wachsender Systemkomplexität unhandlicher.

DOSDrivers

Spätere Systeme bevorzugen einzelne Einträge im Verzeichnis DEVS:DOSDrivers. Diese Dateien können automatisch beim Start berücksichtigt oder per MOUNT aktiviert werden. Praktisch ist das die aufgeräumtere Form derselben Grundidee.

CON:, RAW:, NIL:, PIPE: und Streams

Ein besonders guter Blick auf AmigaDOS ergibt sich an den Standardnamen für Ein- und Ausgabe. Diese Namen zeigen, dass das DOS-Modell nicht nur Dateisysteme kennt, sondern allgemeine Streams. Genau deshalb lassen sich Kommandos umleiten, Ergebnisse verwerfen oder an Konsolenfenster koppeln, ohne für jeden Sonderfall eine andere Syntax zu erfinden.

CON:

CON: steht für einen Konsolenhandler mit Fensterbezug und zeichenverarbeiteter Eingabe. Das ist die „komfortable“ DOS-Konsole: line-buffered, editierbar, benutzerfreundlicher. Genau deshalb ist sie die natürliche Shell-Welt.

RAW:

RAW: ist die rohe Variante. Keine Zeichenaufbereitung, keine komfortable Zeilenbearbeitung, keine zurückhaltende Eingabelogik. Eingaben gehen in unmittelbarer Form durch. Das ist für allgemeine Benutzung unfreundlicher, aber für bestimmte Programme genau richtig.

NIL:

NIL: ist das Wegwerfziel. Alles, was dorthin geschrieben wird, verschwindet. Das ist nicht spektakulär, aber praktisch – besonders in Skripten und Hintergrundstarts, wenn störende Ausgaben bewusst unterdrückt werden sollen.

PIPE:

PIPE: gehört in dieselbe DOS-Welt: ein Pseudogerät für Datenkopplung zwischen Prozessen oder Kommandoströmen. Dazu kommt in späterer Dokumentation noch der interne Shell-Befehl PIPE, der die Stream-Verkettung innerhalb der Shell abbildet. Für den praktischen Benutzer bleibt aber die wichtigere Erkenntnis: In AmigaDOS sind auch solche Verbindungen namen- und streamförmig modelliert, nicht als exotischer Sondermodus neben dem restlichen System.

Run, Execute und Startmodelle

Im Alltag merkt man den DOS-Charakter des Systems besonders deutlich daran, wie Programme und Kommandofolgen gestartet werden. Interaktiv bedeutet: Das Kommando läuft im aktuellen Shell-Kontext. RUN bedeutet: DOS startet die Ausführung im Hintergrund bzw. in einem eigenen Prozesskontext weiter. EXECUTE bedeutet: Die Shell liest Kommandos aus einer Datei und arbeitet sie als Skript ab.

Interaktive Ausführung

Tippt man ein Kommando direkt in die Shell, läuft es in deren laufendem CLI-Kontext. Standard-Ein- und Ausgabe, CurrentDir, Promptzustand und Redirects gehören zu dieser Umgebung. Das ist die normale, unmittelbare DOS-Arbeit.

RUN

RUN startet eine Befehlsfolge so, dass die Shell weiterbenutzbar bleibt. Praktisch bedeutet das: DOS erzeugt einen neuen Ausführungskontext mit derselben Prioritätsidee und lässt die aktuelle Shell weiterlaufen. Dadurch wird Multitasking im Alltag unmittelbar sichtbar – ohne dass man dafür erst in eine GUI-Welt wechseln müsste.

EXECUTE

EXECUTE liest Kommandos aus einer Skriptdatei. Das ist keine Nebensache, sondern Kern des DOS-Stils. AmigaDOS ist nicht nur interaktive Kommandozeile, sondern sehr bewusst auch Skriptumgebung. Parameterersetzung, Kontrollfluss, Rückgabecodes und Redirects gehören in diese Welt.

Wichtig ist der Unterschied: RUN verschiebt Arbeit in einen eigenen Laufkontext. EXECUTE bedeutet nicht automatisch Hintergrundarbeit, sondern Skriptausführung als DOS-Befehlsquelle.

Shell-Skripting und Redirects

Die Shell ist im AmigaDOS nicht bloß ein Eingabefenster. Sie ist ein DOS-Frontend mit Redirects, Skriptlogik und Kontrollstrukturen. Genau deshalb gehören Dinge wie IF, ELSE, ENDIF, FAILAT, ASK, LAB, SKIP, QUIT oder EXECUTE in dieselbe Welt wie Datei-I/O und Prozessstart.

Redirection

Mit > und < lenkt die Shell Standard-Ausgabe oder Standard-Eingabe auf Dateien oder Geräte um. Das ist ein echter DOS-Mechanismus, kein bloßes Komfortdetail. Dadurch können Kommandos gegen Dateien, Konsolen, Drucker oder Pseudogeräte arbeiten, ohne selbst speziell dafür geschrieben zu sein.

Skriptdateien

Skripte sind einfache ASCII-Dateien. Klassisch liegen sie oft in S:. Wird das Skript mit dem s-Schutzbit versehen, kann es direkter wie ein Kommando gestartet werden. Das wirkt selbstverständlich, ist aber genau Ausdruck der DOS-Philosophie: Textdatei, Befehlsfolge, kontrollierte Umgebung.

Wichtige Praxisdateien

• S:Startup-Sequence – zentrale Startsequenz des Systems.
• S:User-Startup – benutzerseitige Ergänzungen, ohne die Hauptsequenz grob anzufassen.
• S:Shell-Startup – Shell-spezifische Initialisierung einer neu geöffneten Shell.

Warum das bemerkenswert ist

Viele Systeme der Zeit hatten entweder eine Kommandozeile oder eine grafische Oberfläche. AmigaOS hatte beides – und im DOS-Bereich eine Skriptkultur, die tatsächlich systemnah war. Man steuerte nicht nur Anwendungen, sondern Teile der Umgebung selbst mit denselben Mitteln: Text, Kommandos, Redirects, Assigns, Mounts, Startsequenzen.

„Die Stärke von AmigaDOS liegt nicht in einer spektakulären Syntax. Sie liegt darin, dass dieselben einfachen Mittel an vielen Stellen tragen.“

Was an AmigaDOS eigentlich stark ist

Die eigentliche Stärke von AmigaDOS ist nicht, dass es besonders modern klingt. Im Gegenteil: An vielen Stellen spricht seine Herkunft offen mit. BPTR, BSTR, Handler, Packet-Welt, CLI-Strukturen – all das wirkt nicht glattgebügelt. Genau daraus entsteht aber eine Qualität, die viele spätere Systeme nicht mehr in derselben Klarheit hatten: ein überschaubares Modell.

Namen werden aufgelöst. DOS spricht mit Handlern. Prozesse haben einen expliziten DOS-Kontext. Streams sind umleitbar. Assigns erweitern den Namensraum. Skripte sind einfache Textdateien. Mount-Einträge sind lesbare Konfiguration. Man kann das System Stück für Stück verfolgen, ohne ständig gegen verdeckte Komplexität anzulaufen.

Das heißt nicht, dass AmigaDOS perfekt wäre. Es heißt nur, dass seine Struktur lesbar bleibt. Und gerade das macht die Schicht bis heute interessant: nicht als Nostalgieobjekt, sondern als Beispiel dafür, wie weit man mit wenigen, klaren Grundideen kommen kann.