Einen einfachen Verbindungsweg zwischen den Betriebssystemen CP/M-80 von Digital Research, TRS-DOS von Radio Shack und Apple-DOS von Apple wollte die Microsoft GmbH, Taufkirchen, schaffen. Wolfgang Bartel beschreibt, warum man sich für die Verbindung zwischen CP/M-80 und dem hauseigenen MS-DOS entschied.
Bei der Erfüllung dieser Aufgabe erwarteten wir keine allzu großen Schwierigkeiten, da der 8080- und Z80-Mikroprozessor dem 8086-Prozessor sehr ähnelt. Es blieb die Wahl zwischen CP/M-80 und TRS-DOS. Apple-DOS schied aus, da dieses Betriebssystem auf einem 6502-Prozessor zu Hause ist.
Obwohl CP/M-80R nicht das am häufigsten installierte Betriebssystem darstellt, so wird es jedoch von den meisten Systemherstellern unterstützt. Lediglich Radio Shack und Apple bildeten hier eine Ausnahme. Deshalb erschien es logisch, zwischen CP/M-80R und MS-DOS einen Verbindungsweg herzustellen.
In unserer Version 1.0 von MS-DOS emulierten wir bereits eine Reihe von System-Calls und setzten dies in der Version 2.0 fort. Das hat für den Systementwickler folgenden Vorteil: Bei Vorhandensein von CP/M-80R-Source-Code kann das entsprechende Programm einfach einen Mikrosoft-Assembler-Übersetzer durchlaufen, um als 8086-Programm in den meisten Fällen unter MS-DOS sofort lauffähig zu sein. Damit hatten wir den angestrebten Verbindungsweg zwischen der 8-Bit-Welt und der 16-Bit-Welt erreicht.
Wir haben außerdem einen Verbindungsweg zwischen der Unix-Welt (typisch für Minicomputer) und der Xenix-Welt (typisch für Mikrocomputer) erzeugt. Dies war hauptsächlich durch den Einsatz der Programmiersprache "C" möglich, da diese Sprache bei der Erstellung von Unix Verwendung fand und sehr leicht auf andere Systeme zu übertragen ist.
Festplatte gesteuert
In unserer Version von Unix wurde diesem Umstand Rechnung getragen. Somit können alle Programme, die unter Xenix entwickelt wurden, auf allen Systemen mit der entsprechenden Mikroprozessorumgebung laufen, das heißt, es gelang uns, auch zwischen Unix und der 16-Bit-Welt eine Verbindung zu schaffen.
Die erste Neuheit in MS-DOS 2.0 ist der vom Anwender selbst installierbare Device Driver. Ein solcher Device Driver repräsentiert den Hardware-spezifischen Teil eines Betriebssystems. Mit diesem Baustein wird eine Festplatte (die möglicherweise an einen Mikrocomputer angeschlossen werden soll) gesteuert, ebenso wie eine betimmte Tastatur oder ein spezieller Bildschirm.
Diese Steuerung ist von Hersteller zu Hersteller unterschiedlich. Bis heute war es die Aufgabe des jeweiligen Hardware-Herstellers, für das entsprechende BIOS zu sorgen, um das entsprechende - Betriebssystem auf seiner Maschine lauffähig zu machen.
Dies erzeugte beträchtliche Schwierigkeiten für den jeweiligen OEM, der gerne seine eigene Hardware an die Hardware eines anderen Herstellers anschließen wollte. Da jeder System-Hersteller sein eigenes BIOS besitzt, mußte eine von zwei Möglichkeiten gewählt werden: Entweder das entsprechende BIOS mußte völlig neu geschrieben werden, mit dem Zusatz-Code für die entsprechende Peripherie, oder eine eigene Routine wurde erstellt, die das "Ur-BIOS" einlas, änderte, den Zusatz-Code hinzufügte und dann als neuer Driver-installiert werden mußte.
Eine solche Prozedur ist sehr aufwendig und muß jedesmal neu erstellt werden, wenn eine neue Version des Ur-BIOS ausgeliefert wird. Durch die Verwendung eines installierbaren Device Drivers ist es jetzt möglich, die oben genannten Routinen zu umgehen.
Beispiel: Will ein Anwender zwischen VT-52 und ANSI-Cursor-Positionierung schalten, kann er einfach den beliebigen Device Driver installieren. Ebenso kann er zu einem späteren Zeitpunkt genauso leicht den Virtual Device Interface-Grafik-Driver einsetzen oder das AT&T Presentation Level Protocol verwenden.
Kompatibel zu Xenix
Die zweite Neuheit bei MS-DOS 2.0 ist die Kompatibilität zu Xenix. Das Dateiverwaltungssystem in Xenix wurde in die Version 2.0 mit aufgenommen. Außerdem wurden Exec System Calls von Xenix implementiert. Diese Funktionen erlauben die Verarbeitung von hierarchisch aufgebauten Tasks.
Die Struktur des File Directorys von MS-DOS 2.0 wurde ebenfalls verbessert zu einem hierarchisch aufgebauten Dateisystem. Das Dateisystem ist nun in der Lage, unter verschiedenen Benutzerberichten und unterschiedlichen Bereichen innerhalb eines bestimmten Benutzer-Directorys zu unterscheiden.
Als "Interprocess Communication" von Xenix ist eine begrenzte Form von "Piping" in MS-DOS 2.0 möglich. Unsere Form erlaubt dem Anwender die Ausgabe des einen Prozesses, automatisch durch das Betriebssystem bewirkt, als Eingabe für einen anderen Prozeß zur Verfügung zu stellen. Ein klassisches Beispiel hierfür ist das Sortieren eines Directorys:
Das Inhaltsverzeichnis wird durch den entsprechenden Befehl aufgerufen und die Ausgabe einer Routine zugeführt, die dann das Inhaltsverzeichnis sortiert. Dieser Vorgang geschieht automatisch durch das Betriebssystem. Ein anderes Beispiel wäre die Funktion "More", welche die Bildschirmausgabe in jeder 24. oder 25. Zeile stoppt, um den Bildschirminhalt besser lesbar zu machen; die Funktion "Cypher" für die Codierung bestimmter Textteile, um wichtige Informationen vor unbefugtem Zugriff zu schützen.
Eine weitere Verbesserung in MS-DOS 2.0 ist die Möglichkeit der Verwendung von internationalen Zeichensätzen, wobei intern grundsätzlich der volle 8-Bit-Zeichensatz verwendet wird. MS-DOS 2.0 besitzt einen System-Call, der wichtige Informationen über die internationale Umgebung bereitstellt. Das Betriebssystem liefert Informationen über die unterschiedlichen numerischen Darstellungen in den einzelnen Ländern:
Wird als Dezimalstelle ein Punkt oder Komma verwendet? Wie wird die Tausenderstelle gekennzeichnet? Welche Bezeichnung hat das Währungssymbol? Steht es vor oder hinter den Beträgen, wie viele Kommastellen sind üblich?