MS-DOS Architektur


Ein MS-DOS-System läuft immer auf Computern, die dem Industriestandard entsprechen, kurz diejenigen, die früher IBM-kompatibel genannt wurden. Diese Fixierung auf eine bestimmte Hardware bringt sowohl beim Start, als auch bei der Architektur von DOS eine starke Bindung an das BIOS des Rechners, des grundlegenden Ein-/Ausgabe Systems (Basic Input Output System).

Grundsätzlicher Aufbau von Computersystemen

Um die wesentliche Architektur eines Computers zu verstehen, muß man zwischen wichtigen Teilen eine gedankliche Trennung ziehen und die Interaktionen zwischen den verschiedenen Teilen einer genaueren Betrachtung unterziehen.

Grundsätzlich (also unabhängig vom Betriebssystem) können wir den Computer in Hard- und Software einteilen. Selbstverständlicherweise müssen diese beiden Teile miteinander auf die vielfältigste Weise in Kontakt treten. Vereinfacht dargestellt können wir uns so an ein Schichtenmodell herantasten, zunächst also nur die Trennung in Hard- und Software:

Software Hardware

Software Hardware (Bild 1)

Würde es bei dieser Trennung bleiben, so müsste jedes Programm also genauestens über die verwendete Hardware Bescheid wissen. Im Grunde genommen wären Änderungen an der Software nötig, wenn eine Speichererweiterung vorgenommen werden würde. Völlig undenkbar wäre die Übertragbarkeit eines solchen Programms auf einen Computer eines anderen Herstellers (obwohl kompatibel).

Die Hardware ist aber natürlich das A und O eines Computers, sowohl die Eingabe als auch die Ausgaben eines Programms beziehen sich immer auf Hardware, jeder Speicherzugriff ist Zugriff auf die Hardware, selbst das Laden eines Programmbefehls in den Prozessor ist irgendwo Zugriff auf Hardware.

Der Knackpunkt zur Kompatibilität liegt im BIOS, der Software, die auf dem Mainboard des Computers enthalten ist. Das BIOS ist tatsächlich für exakt den Computer geschrieben worden, auf dessen Mainboard es sitzt. Es weiß genauestens über die Hardware Bescheid, und bietet auf der anderen Seite aber standardisierte Ein-/Ausgaberoutinen an.

Ein Programm kann jetzt, ohne selbst über die Hardware Bescheid zu wissen, auf diese zugreifen weil es nicht direkt zugreift, sondern über das BIOS. Das BIOS stellt auf der einen Seite eine spezifische Verbindung zur Hardware dar, auf der anderen Seite stellt es standardisierte Routinen zur Verfügung, die Programme nutzen können um auf Hardware zuzugreifen.

Software 2 PCs

Software 2 PCs (Bild2)

Damit sind wir schon einen guten Schritt weiter auf dem Weg zum Schichtenmodell, ein wesentlicher Punkt fehlt aber noch. Beim vorliegenden Modell müsste immer noch jedes Programme relativ genau über die Resourcen Bescheid wissen, die es benutzen will. Allein das Laden eines Programmes, die Zuteilung von Arbeitsspeicher, die Verhinderung von Gerätezugriffskonflikten, all das verlangt nach einer weiteren Schicht, die sozusagen als Kontrollinstanz zwischen dem BIOS und dem Anwenderprogramm fungiert.

Diese Funktion übernimmt das Betriebssystem, in unserem Fall also MS-DOS. Das Betriebssystem stellt Mechanismen zur Verfügung, die es erlauben, Programme zu laden, die Programmen Zugriff auf Hardware erlauben und die die wesentlichen Ein-Ausgabeschnittstellen zum Benutzer steuern. Vervollständigt sähe unser Schichtenmodell also folgendermaßen aus:

Hardware Bios Betriebssystem Anwenderprogramme

Hardware Bios Betriebssystem Anwenderprogramme (Bild3)

Dieses Model ist immer noch für alle verschiedenen Betriebssysteme wie DOS, OS/2, WindowsNT, Windows95 oder Unix gültig. Die weitere Betrachtung bezieht sich hier jetzt auf die Architektur von MS-DOS.

Aufbau von MS-DOS

Nachdem jetzt geklärt ist, wo innerhalb des Schichtenmodels das Betriebssystem steckt, können wir uns dem internen Aufbau von MS-DOS zuwenden. Im Vergleich zu modernen Systemen sind die Aufgaben von MS-DOS relativ überschaubar, weil dieses System keinerlei Mechanismen zum Schutz vor unberechtigtem Zugriff, zur Verhinderung von konkurrierenden Gerätezugriffen oder gar zur Steuerung mehrerer, gleichzeitig laufender Programme besitzt.

Das eigentliche Betriebssystem MS-DOS besteht aus nur drei Dateien, alle weiteren Programme und Dateien sind Zusätze, die zwar wichtig für den täglichen Betrieb sind, aber nicht existenziell für die Funktion des Betriebssystems. Die drei wichtigen Dateien sind:

  • IO.SYS
  • MSDOS.SYS
  • COMMAND.COM

Im Prinzip ist eine Diskette, die diese drei Dateien (an den richtigen Stellen) enthält, eine funktionsfähige Bootdiskette. Selbst auf einem Rechner ohne Festplatte wäre es möglich, ein Programm mit dieser Diskette zu starten. Die beiden .SYS Dateien sind versteckt, durch einen DIR Befehl lassen sie sich nicht darstellen.

Jede dieser drei Dateien hat spezifische Funktionen, die hier kurz dargestellt werden sollen:

IO.SYS

Die Datei IO.SYS hat zwei wesentliche Teile, zum einen die Steuerung des Ladevorgangs des weiteren Systems (SYSINIT) und zum anderen die Bereitstellung der Gerätedateien und -schnittstellen.

Die Gerätedateien sind Softwareschnittstellen, die Hardware ansprechen. Um sie für DOS-Programme zugänglich zu machen, werden die Geräte wie Dateien verwaltet, es kann in eine Datei geschrieben und aus einer Datei gelesen werden. Genauso kann auf ein Gerät geschrieben und von ihm gelesen werden.

Die Standardgeräte, die IO.SYS anlegt sind:

Diskettenlaufwerke keine Bezeichnung
Systemuhr CLOCK$
Par. Schnittstellen LPT1-LPT3, PRN
Ser. Schnittstellen COM1-COM4, AUX
Tastatur/Monitor CON

Über diese Gerätedateien ist der direkte Zugriff auf Geräte möglich, so kopiert beispielsweise folgender Befehl eine Datei zum Drucker auf dem ersten Druckerport (LPT1):

  COPY TESTDAT LPT1

Kurz gesagt stellt IO.SYS also die Schnittstellen zu den wichtigsten Ein-/Ausgabegeräten her. (Unschwer zu erraten, woher die Datei ihren Namen hat…) Es ist also diese Datei, die direkt mit dem BIOS des Rechners kommuniziert, und die dessen standardisierte Schnittstellen verwaltet. (Siehe Bild 2)

Die zweite Aufgabe von IO.SYS ist die Steuerung des Systemladevorgangs, sie läd die weiteren Betriebssystemdateien in den Speicher, insbesondere die Datei MSDOS.SYS

MSDOS.SYS

Diese Datei enthält den eigentlichen Betriebssystemkern (Kernel), der MS-DOS erst in die Lage versetzt, Laufwerke und Dateien zu verwalten, Speicher zuzuweisen, Programme zu kontrollieren und das System für verschiedene Sprachen und Tastaturlayouts vorzubereiten. Außerdem werden hier auch die höherliegenden Gerätetreiber verwaltet, die nicht schon in IO.SYS eingerichtet wurden. Dazu zählen alle Treiber, die in der Datei CONFIG.SYS angegeben werden.

Streng genommen wird die Datei CONFIG.SYS zwar vom SYSINIT-Teil der IO.SYS abgearbeitet, die Schnittstellen werden aber direkt von MSDOS.SYS verwaltet. Die Treiber, die in der Datei CONFIG.SYS eingetragen sind, können nicht mehr von IO.SYS verwaltet werden, weil sie ja nichts mit dem BIOS selbst zu tun haben sondern in der Regel Geräte ansprechen, die dem Computer nachträglich eingebaut wurden und ihm daher unbekannt sein müssen. Die Verwaltung dieser Treiber übernimmt MSDOS.SYS, also das eigentliche Betriebssystem.

Wichtig für Programmierer ist, daß MSDOS.SYS auch die vielen hundert Interrupts zur Verfügung stellt, die zur Steuerung eines Systems nötig sind. (Vorsicht ist hier angesagt, es gibt auch BIOS-eigene Interrupts, die unabhängig vom verwendeten Betriebssystem funktionieren.)

COMMAND.COM

Damit Anwender und Anwenderprogramme überhaupt mit dem Betriebssystem kommunizieren können, muß es noch eine Schnittstelle nach außen geben, eine Schnittstelle zum Benutzer. Diese Aufgabe wird von COMMAND.COM übernommen, dem Kommandointerpreter. Er ist es, der uns den Prompt zur Verfügung stellt und Eingaben erwartet. Er ist es auch, der die Eingaben interpretiert und verarbeitet. Er startet Kommandos, führt Batch-Dateien aus und stellt die internen Befehle zur Verfügung. Alles, was wir als Anwender mit dem Betriebssystem zu tun haben regelt der Kommandointerpreter. Die Datei COMMAND.COM ist logischerweise auch die einzifge der drei Systemdateien, die nicht versteckt ist.

Der Kommandointerpreter ist es auch, der die internen Befehle von MSDOS beinhaltet. Sie werden nirgends eine Datei namens DIR.EXE oder COPY.EXE finden, diese Befehle sind Teil des Kommandointerpreters also interne Befehle. Wichtigstes Merkmal dieser internen Befehle ist, daß sie immer zur Verfügung stehen, selbst auf unserer Minimalbootdiskette. Im Gegensatz dazu müssen die externen Befehle als ausführbare Datei im Suchpfad gefunden werden können.

Ein weiteres wichtiges Merkmal des Kommandointerpreters ist die Fähigkeit, Umgebungsvariablen zur Verfügung zu stellen, die von verschiedenen Programmen verwendet werden können. Wir werden mit solchen Variablen bei der Batch-Programmierung noch zu tun haben.

Die nächste wichtige Fähigkeit von COMMAND.COM bezieht sich auf die Ausführbarkeit von BATCH-Programmen, also Textdateien, die mehrere Befehle enthalten, die stapelweise (batch – engl. Stapel) abgearbeitet werden sollen. Eine dieser Batchdateien ist immer von besonderm Interesse, die Datei AUTOEXEC.BAT wird von COMMAND.COM automatisch beim Start abgearbeitet. Ahnlich wie die CONFIG.SYS bei der Initialisierung von MSDOS.SYS bietet die Datei AUTOEXEC.BAT für COMMAND.COM die Möglichkeit, individuell eingestellt zu werden.

Abschließend muß noch erwähnt werden, daß es durchaus möglich ist, den COMMAND.COM durch Fremdprodukte zu ersetzen. MS-DOS bietet sogar extra einen Befehl für die CONFIG.SYS (COMSPEC) an, der einstellt, welcher Kommandointerpreter verwendet werden soll.

Zusammengefasst könnte unser Schichtenmodell jetzt also für MSDOS folgendermaßen aufgebaut sein:

Autoexec.bat

Autoexec.bat (Bild4)