c't 7/91 Seite 58

Microsofts Fünfte

MS-DOS 5.0

Harald Albrecht

Obwohl bereits mehrmals voreilig mit einem Trauermarsch beerdigt, erlebt das `Industrie-Standard-Betriebssystem´ MSDOS zur Zeit einen zweiten (oder gar dritten) Frühling. Eine neue Komposition à la Microsoft war daher längst überfällig. Dem Anwender stellt sich mit der neuen Version aber die Frage, ob sich der Umstieg lohnt, ohne dass durch die neuen Betriebssystem-Töne das bisherige so harmonische Applikations-Arrangement mit Missklängen getrübt wird.

Die längere Verschnaufpause zwischen der Version 4.01 und der neuen Version 5.0 hat mit Sicherheit dem Betriebssystem nicht geschadet - so kann der Eindruck eines hektischen oder lieblosen Updates gar nicht erst aufkeimen. Microsoft hat die Zeit sinnvoll dazu genutzt, nicht nur die alten Dienstprogramme zu überarbeiten, sondern auch neue und nützliche hinzuzufügen. Nicht einmal der Betriebssystemkernel blieb verschont, er glänzt mit erweiterten Fähigkeiten zur Speicherverwaltung.

Auf die Kompatibilität zur Vorgängerversion wurde dabei Wert gelegt, so dass im Gegensatz zum Sprung zwischen den Versionen 3.3 und 4.01 beim Wechsel zur neuesten Version des Betriebssystems kaum Probleme auftreten dürften. Software, die bisher klaglos ihren Dienst unter der Version 4.01 verrichtete, kommt auch in den allermeisten Fällen mit MSDOS 5.0 zurecht, wenn sie nicht gerade ausschweifenden Gebrauch von versionsabhängigen internen Betriebssystemtabellen macht. Für die meisten in besonderem Maße davon betroffenen Netzwerk-Shells, die für das Vortäuschen von Netzwerklaufwerken zuständig sind, liefert Microsoft gleich Ersatz mit. So finden sich auf den Betriebssystemdisketten neue angepasste Shells für den Microsoft LAN Manager, Novells Netware und IBMs PCLP.

Die bisher im Einsatz befindlichen Disketten- und Festplatten-Tools kommen mit der Version 5.0 im Normalfall problemlos aus, sofern sie für MSDOS 4.01 geeignet sind. Die dort eingeführte Unterstützung von Festplatten-Partitionen mit einer Größe von mehr als 32 MByte findet sich unverändert auch in der Version 5.0 wieder. Allerdings mahnt das Betriebssystem endlich nicht mehr bei jedem Booten an, dass man doch bitteschön SHARE.EXE für größere Partitionen installieren möge. Auf die Verschwendung der dafür benötigten 6 KByte kann man nun in den allermeisten Fällen getrost verzichten. Neu hinzugekommen ist ein 2,88-MByte-Diskettenformat für die kleinen 3,5-Zöller, für die bereits die ersten Laufwerke auf der diesjährigen CeBIT vorgestellt wurden.

Die Installation des Betriebssystems erfolgt komfortabel über ein neues Setup-Programm, das vom Stil her an das beispielsweise von Windows 3.0 verwendete Pendant erinnert. Das Update von der bisherigen MSDOS-Version auf das neue MSDOS 5.0 erfolgt dabei sehr elegant ohne Neuformatieren des Bootlaufwerks. Bereits nach etwa 10 bis 15 Minuten kann man mit der neuen Version arbeiten. Zugleich erstellt das Installationsprogramm eine Systemdiskette mit dem alten Betriebssystem, so dass man bei unvorhergesehenen Schwierigkeiten notfalls den alten Zustand wieder restaurieren kann. Das Herumjonglieren mit einer zusätzlichen Hilfs-Diskette, von der man während der Installation bisher booten musste, entfällt damit - zumindest beim Update.

Neue dienstbare Geister

Obwohl die Möglichkeiten, die Eingabezeile hinter dem DOS-Prompt zu editieren, im Vergleich zum CP/M zwar zahlenmäßig riesig sind, ist der `Komfort´ in der Praxis wohl nur als `grundlegend´ zu charakterisieren. Einzig die letzte Eingabe kann man nochmals editieren (nach Murphy benötigt man jedoch grundsätzlich immer die zweitletzte Eingabe). Abhilfe boten hier bislang nur Utilities wie beispielsweise CED, mit deren Hilfe sich die Eingaben komfortabel editieren lassen. MSDOS 5.0 bietet nun in seinem Dienstprogramm-Fundus ein `offizielles´ Utility namens DOSKEY, mit dessen Hilfe man Eingabezeilen mit den Cursortasten sowie Ins und Del bearbeiten kann.

Außerdem legt DOSKEY jede mit Enter abgeschlossene Zeile in einem History-Buffer ab, auf den der Benutzer mit den Cursortasten zugreifen kann. Weiterhin kann er sich Makros anlegen, indem er einer Zeichenkette einen oder mehrere DOS-Befehle zuordnet. Trotz des Bedienungskomforts, den DOSKEY bietet - und den ich nicht mehr missen möchte -, belegt dieses Dienstprogramm nur etwa 3,5 KByte. Unverständlicherweise profitieren andere Programme wie DEBUG oder EDLIN, die für Eingaben die entsprechende DOS-Funktion benutzen, nicht von DOSKEY - beim Vorbild CED funktioniert das jedoch problemlos.

Serienmäßig bietet MSDOS 5.0 nun auch Tools, um Datenverluste durch irrtümliches Löschen von Dateien oder durch Formatieren der Festplatte zu verhindern. Die dafür zuständigen Programme MIRROR, UNDELETE sowie UNFORMAT stammen von Central Point und werden von Microsoft in Lizenz mitgeliefert (Peter Norton wird´s ärgern). Funktional entsprechen die Utilities ihren Pendants von den PC Tools. Mit MIRROR lässt sich im Speicher ein kleines Überwachungsprogramm installieren, das Informationen über gelöschte Dateien sammelt. Mit diesen Daten kann man via UNDELETE eine gelöschte Datei wiederbeleben, solange DOS den ursprünglich belegten Platz noch nicht anderweitig vergeben hat.

Unverständlicherweise existiert immer noch kein Befehl, um eine oder mehrere Dateien über Verzeichnisgrenzen hinweg zu verschieben; man muss sie nach wie vor umkopieren und dann löschen. Ein solches Dienstprogramm wäre nun wirklich nicht aufwendig, dafür bei der täglichen Datenpflege aber sehr nützlich. So bleibt gezwungenermaßen nur der Umweg über die DOS-Shell, die sogar solch profane Dinge zu lösen weiß.

Für Software, die partout nur mit einer bestimmten MSDOS-Version arbeiten möchte, bietet Microsoft Abhilfe. Es genügt, mit Hilfe des Dienstprogramms SETVER für ein bestimmtes Programm die zu vermeldende Versionsnummer in das Betriebssystem einzutragen. Damit ist das Problem dann aus der Welt geschafft, denn MSDOS gaukelt diesem Programm ab sofort eine andere Versionsnummer vor. Es gibt aber durchaus auch Software, die bewusst (und nicht versehentlich) auf eine exakte Versionsnummer überprüft, da sie beispielsweise Gebrauch von systeminternen Tabellen macht. Hier hilft dann nur ein Update auf eine angepasste neue Programmversion - soweit verfügbar.

Hoch hinaus

Neue Fähigkeiten der Software werden besonders unter MSDOS mit Argwohn beäugt, da sie zumeist Hand in Hand mit einem erhöhten Speicherappetit einhergehen. Da MSDOS mit seinen 640 KByte nach heutigen Maßstäben alles andere als üppig ausgestattet ist, empfindet der Benutzer jedes zusätzlich vom Betriebssystemkernel belegte KByte als einen besonders schmerzhaften Verlust. Um dem entgegenzuwirken, hat Microsoft den MSDOS-Kernel einer recht erfolgreichen Abmagerungskur unterzogen, die sich unterm Strich gegenüber der Version 4.01 mit ungefähr 5 KByte bemerkbar macht. Eigenen Angaben zufolge soll dafür sowohl eine Code-Optimierung als auch die Behebung einiger `funktionaler Redundanzen´ verantwortlich sein - anscheinend die Umschreibung für die mangelnde Koordination des Entwickler-Teams.

Eine größere zusätzliche Einsparung wartet jedoch auf alle AT-Besitzer, sofern deren System über Extended Memory verfügt. Eine Besonderheit des 80286-Prozessors und aller Nachfolgemodelle macht dies möglich: Dafür verantwortlich sind die gegenüber dem 8088-Prozessor hinzugekommenen Adressleitungen, die dem 80286-AT einen theoretisch 16 MByte großen Adressraum bescheren. Im normalen Betrieb legt eine Schaltung die erste dieser neuen Leitungen (A20) dauerhaft auf Null. Wenn Software die A20-Leitung freigibt, verhalten sich 80286 und alle Nachfolger nicht mehr ganz PC-konform, was die Adressierung im letzten Speichersegment (0FFFFh) angeht. Während auf einem 8088 jede auf 0FFFFh:0Fh folgende Adresse zwangsläufig (getreu der Formel Segment × 16 + Offset) wieder in den Anfang des Speichers (ab 0:0) führt, kann der 80286 damit die ersten 65 520 Byte im Extended Memory erhaschen. Weil dieser Bereich über dem normalen 1-MByte-Adressraum des 8086/88 liegt, trägt er den Namen `High Memory Area´ oder HMA.

Bisher blieb die HMA weitgehend unbeachtet und lag daher zumeist brach. Eine Mitschuld trägt nicht zuletzt die bisher fehlende Verwaltung, da nur jeweils ein Programm diesen Speicher exklusiv für sich nutzen darf. Die Aufteilung an mehrere Programme wäre völlig sinnlos - CP/M lässt grüßen. Nicht einmal die Extended Memory Spezifikation (XMS), die seit MSDOS 4.01 der Treiber HIMEM.SYS zur Verfügung stellt, änderte etwas daran. Und das, obwohl sich der XMS-Manager freundlicherweise gleich um die rechnerspezifische Freigabe der für die HMA benötigten Adressleitung A20 kümmert. Diese ist im Normalfall der Kompatibilität wegen gesperrt, um auf diese Weise exakt den Adressraum des 8086/88 nachzubilden.

Eine sinnvolle Nutzung der HMA durch das Betriebssystem, um so einen Teil des Kernels aus den wertvollen 640 KByte zu verbannen, lag deshalb nahe. Nachdem bereits der Konkurrent Digital Research mit DR DOS 5.0 mit gutem Beispiel voranging und die HMA für den Betriebssystemcode nutzt, zieht nun Microsoft ebenfalls nach. Per Kommando `DOS=HIGH´ in der CONFIG.SYS-Datei lässt sich MSDOS 5.0 anweisen, nicht etwa eine Straftat gegen das Betäubungsmittelgesetz zu begehen, sondern einen großen Brocken seiner selbst dorthin auszulagern. Auf diese Weise erhält der Anwender circa 43 KByte mehr im konventionellen Speicher.

Den noch in der HMA verbleibenden Platz füllt das DOS mit den Disk-E/A-Buffern, Teilen des COMMAND.COM und des XMS-Memory-Managers (HIMEM.SYS) auf. Besonders nützlich ist hierbei die Auslagerung der Buffer, lassen sich doch auf diese Weise bei der Einstellung `BUFFERS=30´ etwa 14,5 KByte Speicher unterhalb der 640-KByte-Marke räumen. Einzig ein einzelner 512 Bytes großer Buffer bleibt einsam für die Abwicklung des Disketten- und Festplatten-Datentransfers im Speicher zurück. Auf diesen Buffer kann DOS auf keinen Fall verzichten, da sich das BIOS bei Adressen hoffnungslos verheddert, die in der HMA liegen.

Gegen ein Überschreiben durch Programme, die am XMS-Manager vorbei Extended Memory reservieren, schützt sich das Betriebssystem bei belegter HMA recht einfach: es täuscht kurzerhand eine RAM-Disk ältester Bauart vor: VDISK. Dieser Treiber belegt das Extended Memory nicht, wie heute weithin üblich, im Top-Down-Verfahren. Statt dessen nutzt er den vorhandenen Speicher von unten her. Getreu dem Vorbild legt MSDOS 5.0 zu Beginn des Extended Memory, also in der HMA, die gleiche markante Kennung wie VDISK ab, so dass auch ältere Software derart belegten Speicher erkennt.

Auf einem durchschnittlich mit Software bestückten System lädt MSDOS möglicherweise, dank der in die HMA ausgelagerten Bestandteile, Programme unterhalb der ersten 64-KByte-Marke. Die allermeisten Programme lassen sich von dieser Tatsache nicht im geringsten beeindrucken und arbeiten wie gewohnt. Mit gepackten EXE-Dateien kann es jedoch Probleme geben, da dort der Auspack-Algorithmus unter Umständen versagt. Es erscheint dann die Meldung `packed file corrupt´. Ein derartiges Programm lässt sich aber mit Hilfe des mitgelieferten Dienstprogramms LOADFIX über die erste 64-KByte-Grenze laden.

Mit Windows 3.0 verträgt sich das Auslagern in die HMA problemlos; Microsoft hat offensichtlich Vorsorge getroffen: Das Installationsprogramm kopiert automatisch eine Datei namens `WINA20.386´ in das Wurzelverzeichnis des Boot-Laufwerks. Windows erkennt diese und lädt sie eigenmächtig. Den unter Windows gestarteten DOS-Applikationen steht analog mehr konventioneller Speicher zur Verfügung.

Löcher stopfen

Die Ressourcen der PC-- Architektur sind damit allerdings noch lange nicht erschöpft; im engen Speicherkorsett kann man immer noch einige RAM-Löcher flicken. Je nach Ausstattung des Rechners mit Grafikkarten, Netzwerkadaptern und ähnlichem liegen einige Adressbereiche von durchaus beachtlicher Größe oberhalb der magischen 640 KByte ungenutzt brach. Für den Bereich zwischen 640 KByte und 1 MByte, der eigentlich für Erweiterungen reserviert wurde, führt MSDOS 5.0 die Bezeichnung `Upper Memory Area´ oder UMA ein.

Wenn man diese Lücken in der UMA nun mit RAM füllt, bietet sich dieser zusätzliche Speicher geradezu als Lagerplatz für residente Programme und Gerätetreiber an. Das dafür nötige RAM kann beispielsweise eine Adapterkarte zur Verfügung stellen. Auf Rechnern mit einem 80386- oder 80486-Prozessor bietet sich statt dessen die im Prozessor integrierte Speicherverwaltungseinheit an, um aus dem Extended-Memory-Pool den notwendigen Speicher zu rekrutieren und unterhalb des ersten MBytes einzublenden.

Indessen war es bisher ein langer und dornenreicher Weg, das Betriebssystem überhaupt von der Existenz dieses Speichers zu überzeugen - wie bereits mehrfach in c't gezeigt [2, 3]. Mit MSDOS 5.0 wird das Procedere zum Glück enorm vereinfacht, da das Betriebssystem nun auch den Speicher in der UMA verwalten und auf Wunsch sowohl Programme als auch die Gerätetreiber dorthin laden kann. Dazu genügt es, bei den betroffenen Zeilen in der CONFIG.SYS-Datei jeweils `DEVICE=´ durch `DEVICEHIGH=´ zu ersetzen. Um das Hochladen der Gerätetreiber robuster zu gestalten, kann man optional mit Hilfe des Parameters `SIZE=hhhh´ den tatsächlichen Speicherbedarf des Treibers angeben. Genügt der aktuell in der UMA verfügbare Platz nicht diesen Erfordernissen, so lädt MSDOS den Treiber automatisch in den konventionellen Speicher.

Bisher konnte sich ein Treiber relativ gefahrlos im Speicher ausdehnen, sollte er während oder für die Zeit nach der Initialisierung mehr Speicherplatz benötigen, als zum Laden notwendig war. In der UMA kann es aber nun passieren, dass eben dieser ausgeht. MSDOS 5.0 legt daher im Initialisierungs-Anforderungspaket, welches es an den Treiber direkt nach dem Laden schickt, die höchste für den Treiber verfügbare Speicheradresse ab. Es benutzt dazu das Feld, in dem der Treiber später dann das Ende des von ihm belegten Speicherbereichs zurückmeldet. An MSDOS 5.0 angepasste Gerätetreiber können so überprüfen, ob ihnen genügend Speicher zur Verfügung steht und gegebenenfalls eine Fehlermeldung ausgeben.

Normale Programme und residente Utilities lassen sich entsprechend mit dem Kommando `LOADHIGH programmname´ oder einfach mit `LH´ in die UMA verbannen. Auch hier lädt DOS den Programmcode bei Platzmangel stillschweigend in den konventionellen Speicher, eine Fehlermeldung erhält der Benutzer nicht. Seltsamerweise hat Microsoft aber das Pendant zum `INSTALL´-Befehl vergessen, so dass man die betroffenen Programme nur mit LOADHIGH aus der AUTOEXEC.BAT heraus in die UMA verfrachten kann.

Um den UMA-Speicher überhaupt problemlos systemunabhängig einbinden zu können, greift Microsoft auf einen bislang nur wenig beachteten Teil der XMS-Vereinbarung zurück: die `Upper Memory Blocks´ oder UMBs teilen die UMA in einzelne Speicherblöcke auf und sorgen so für eine geregelte Verwaltung dieser. Mit Hilfe zweier Dienstleistungen kann man einen UMB, ähnlich den MSDOS-Funktionen zur Verwaltung des konventionellen Speichers, anfordern und wieder zurückgeben. Weist man MSDOS 5.0 mit `DOS=UMB´ in der CONFIG.SYS-Datei an, diese zu benutzen, so lauert das Betriebssystem während der Bearbeitung dieser Datei auf die Installation eines Gerätetreibers, der UMBs bereitstellt. Diese fordert es dann komplett an und verleibt sie seinem Speicherpool ein.

Dabei ist man allerdings nicht auf einen einzelnen Treiber festgelegt, der die UMBs zur Verfügung stellt. Sollte ein weiterer Treiber sich in den `alten´ XMS-Manager einklinken und nun seinerseits weitere UMBs bereitstellen, so nimmt das Betriebssystem auch diese dankbar auf. Im Gegensatz zum konventionellen Speicher müssen die UMBs nicht zwingend einen zusammenhängenden Bereich in der UMA in Beschlag nehmen. Unseligerweise kann MSDOS aber eigentlich nur einen einzigen Speicherblock verwalten. Um dieses Problem ohne eine Änderung der verwendeten Speicherstruktur zu umgehen (Kompatibilität), greift Microsoft auf den bereits von fast allen anderen Lösungen des 640-KByte-Dilemmas benutzten Trick zurück. Dabei wird jeweils um alle Bereiche, die nicht mit zusätzlichem RAM bestückt sind, ein als belegt markierter Speicherblock eingerichtet, so dass die MSDOS-Speicherverwaltung nicht ins Wanken gerät.

Der von Microsoft mitgelieferte XMS-Manager HIMEM.SYS stellt selbst jedoch keine UMBs bereit. Diese Aufgabe erfüllt auf 80386-Systemen das Programm EMM386.EXE. Er tritt die Nachfolge des bisherigen EMM386.SYS an. Eigentlich handelt es sich dabei um einen EMS-Emulator, jedoch lässt er sich durch die Option `noems´ in einen `Spar-Modus´ schalten, in dem er kein Expanded Memory mehr emuliert. EMM386 verwendet dann die Speicherverwaltungseinheit eines 80386 alleine dazu, RAM in der UMA einzublenden, das dem DOS wiederum als UMBs zur Verfügung steht.

Obwohl EMM386 eine EXE-Datei ist, lässt er sich weiterhin wie gewohnt in die CONFIG.SYS-Datei via `DEVICE=´ als Treiber einbinden. Zusätzlich kann man EMM386 allerdings von DOS-Kommandoebene aus aufrufen, um Statusinformationen zu erhalten oder die EMS-Emulation zu steuern. Endlich unterstützt EMM386 auch die VCPI-Vereinbarung [4], nachdem Microsoft zusammen mit Windows 3.0 bereits eine derart angepasste Version ausliefert. Damit ist ein Manko behoben, das in einer Reihe von Fällen die Zusammenarbeit mit anderer 386-Software ausschloss (so beispielsweise Borlands TD286).

Um eine reibungslose Zusammenarbeit mit Windows 3.0 zu gewährleisten, enthält EMM386.EXE zugleich auch eine Dynamic Link Library (DLL). Windows lädt diese automatisch, sofern der EMM386 im System eingebunden ist. Die Library macht die von Windows benutzte virtuelle Speicherverwaltung mit dem in die UMA eingeblendeten Speicher vertraut. Bedauerlicherweise ist ein nachträgliches Hochladen von Programmen aus einer DOS-Shell heraus unter Windows 3.0 nicht möglich: der MEM-Befehl listet den in der UMA befindlichen Speicher in einer DOS-Shell unter Windows nicht auf. Gleichwohl sind die vor dem Start vom Windows hochgeladenen Programme und Treiber aktiv.

Leider füllt EMM386 die in der UMA verfügbaren Lücken bei automatischer Konfiguration nicht vollständig und nutzt damit diesen Speicherbereich nur teilweise. Einer der Testrechner kopiert beispielsweise das EGA/VGA-BIOS aus seinem angestammten Segment C000h in ein Shadow-RAM ab E000h um - ähnlich verfährt manches COMPAQ-System. Da das VGA-BIOS jedoch nur maximal 32 KByte groß ist, bleiben weitere 64 KByte des Adressraums von E000h:8000h bis F000h:7FFFh ungenutzt liegen - die pure Verschwendung. Doch mit Hilfe der EMM386-Option `I=E800-F7FF´ lässt sich dieser Bereich noch einer sinnvollen Nutzung zuführen. Die umfangreiche Dokumentation zu MSDOS 5.0 erwähnt ausgerechnet diesen Schalter nicht.

Bevor Software in die UMA gelangt und dort auch ihren Speicherbedarf decken kann, ist zunächst die UMA freizuschalten. Aus Kompatibilität zu den bisherigen DOS-Versionen liefert die Funktion 48h `Allocate Memory´ ohne weitere Maßnahmen nur Adressen von Speicherblöcken im konventionellen Speicher. Um die Speicheranforderungen auf die UMA auszuweiten, steht die neue Funktion 5803h `Set UMB Link Status´ bereit. Vor dem Aufruf dieser sollte sich die jeweilige Software jedoch davon überzeugen, dass es sich überhaupt um MSDOS 5.0 handelt.

Als weitere Maßnahme sollte jede Applikation, die den `UMB Link Status´ verändert, diesen zuvor abfragen (Funktion 5802h, `Get UMB Link Status´) und bei Programmende (auch durch Ctrl-C) den alten Zustand wiederherstellen. Dieses Vorgehen schreibt die Microsoft-Dokumentation zwar nicht vor, es ist aber sehr zu empfehlen, da MSDOS den Link Status bei Programmende nicht automatisch restauriert. Ein nachfolgend geladenes Programm könnte ansonsten ins Trudeln geraten, falls es mit Speicheradressen über A000h nicht umgehen kann.

Sogar die Funktionen zur Abfrage (5800h) und zum Setzen (5801h) der Speicher-Anforderungs-Strategie berücksichtigen jetzt die UMA. Das dem Strategie-Code hinzugefügte Bit 7 entscheidet nun darüber, ob DOS zuerst im konventionellen Speicher (Bit 7=0) oder in der UMA (Bit 7=1) mit der Suche nach einem passenden Speicherblock beginnt. Leider hat die `best fit´-Strategie in Verbindung mit dem Start der Suche in der UMA so ihre Tücken, da dabei der beste Treffer in der UMA zählt. Einen größeren freien Block im konventionellen Speicher ignoriert diese Strategie-Konstellation. Erst bei einem Misserfolg der Suche in der UMA erinnert sich das Betriebssystem an den konventionellen Speicher - gleiches gilt im umgekehrten Fall, wenn die Suche in den unteren 640 KByte beginnt.

Neue Umgangsformen

Statt durch Benutzerfreundlich- keit glänzte MSDOS bisher vor allem durch herbe Schlichtheit. Oft genug musste der Anwender die Funktionalität dem Betriebssystem regelrecht abtrotzen - denn wer kann schon auswendig alle Optionen von MODE oder XCOPY aufzählen. MSDOS 5.0 gibt sich dabei nun wesentlich hilfsbereiter - zumindest auf Nachfrage - und übernimmt endlich eine bereits seit langer Zeit von der restlichen Software geübte Praxis.

Jedem Dienstprogramm kann der Benutzer eine kurze Hilfestellung mit einer Erläuterung der verfügbaren Parameter entlocken, wenn man es mit `/?´ aufruft. Ebenso stehen die internen Kommandos wie beispielsweise `dir´ oder `copy´ bei Bedarf dem Benutzer Rede und Antwort. Das lästige Wälzen der DOS-Handbücher kann damit in den meisten Fällen unterbleiben, wenn ein Dienstprogramm wieder einmal die nichtssagende Meldung `Falscher Parameter´ ausspuckt. Leider konnte sich Microsoft nicht dazu durchringen, die Fehlermeldungen hilfreicher zu gestalten. Es bleibt so nur noch zu hoffen, dass wenigstens bei den Hilfestellungen nicht wieder der bisherige Übersetzer erbarmungslos zuschlägt...

Sollte der Benutzer nicht mehr wissen, welches Dienstprogramm jeweils für seine Bedürfnisse zuständig ist, so kann er sich mit dem Kommando `HELP´ eine vollständige Übersicht ausgeben lassen. Zu jedem Programm wird hier in ein oder zwei Sätzen der Verwendungszweck erläutert. Diese Angaben lassen sich aber auch gezielt für ein einzelnes Dienstprogramm mit `HELP progname´ erfragen. Eine Erweiterung oder Überarbeitung dieser Übersicht ist zudem einfach möglich, da sie als ASCII-Klartext in der Datei DOSHELP.HLP vorliegt.

Neben den Hilfestellungen bietet COMMAND.COM noch ein paar weitere nette Beigaben. Bisher scheiterte das Piping mittels `|´ immer dann, wenn im aktuellen Laufwerk eine schreibgeschützte Diskette lag. Dieser Unsitte, auf dem aktuellen Laufwerk die für das Piping benötigten temporären Dateien einzurichten, wirkt nun die Environment-Variable `TEMP´ entgegen. Sie gibt den Pfad an, in dem der Kommandointerpreter die temporären Dateien ablegen soll.

Eine weitere Environment-Variable namens `DIRCMD´ steuert die Standard-Optionen des `dir´-Befehls, dessen Optionen in der neuen Version mächtig zugenommen haben. So lassen sich beispielsweise alle Datei- und Verzeichnisnamen alphabetisch ausgeben, ohne dass man dazu SORT bemühen müsste. Sogar nach Extension, Datum und Dateigröße kann der DIR-Befehl nun selbstständig sortieren (auf Wunsch in umgekehrter Reihenfolge). Über die Dateiattribute lässt sich die Ausgabe weiter einschränken. Ferner erstreckt sich die Suche bei Bedarf auch auf Unterverzeichnisse.

Ein wahrhaft revolutionärer Umsturz findet gleichzeitig in einem bisher von allen Neuerungen gemiedenen Bereich statt. Dem CP/M-Relikt EDLIN stellt Microsoft in der fünften Generation des Betriebssystemes einen Full-Screen-Editor namens EDIT zur Seite. Dieser schreckt sogar vor der Unterstützung eines so dekadenten Gerätes wie der Maus nicht zurück. Die selbst auferlegte Beschränkung auf Dateibröckchen von höchstens 64 KByte gehört ebenso wie die maximale Zeilenlänge von 255 Zeichen endlich der Vergangenheit an. Zudem bietet jederzeit eine Hilfestellung ihre Dienste an. Aber keine Angst, für diejenigen, die es lieber rustikal lieben, gibt es auch fürderhin immer noch EDLIN.

Neue Muschel

Von Überarbeitungen blieb nicht einmal die DOS-Shell verschont. Sie präsentiert sich nun in einem leicht überarbeiteten Gewand, das sich teilweise am von Windows 3.0 bekannten Datei-Manager orientiert. So erscheinen im Verzeichnisbaum nun die einzelnen Verzeichnisse als kleine Ordner-Sinnbilder, die beim Anklicken ihre Unterverzeichnisse ein- oder ausblenden.

Die Dateiauswahl geht mit der Maus und zusätzlich der Shift- und/oder Ctrl-Taste gegenüber der alten Version wesentlich komfortabler von der Hand. Genauso wie im Windows-Datei-Manager dienen Maus und Shift-Taste zum Markieren der letzten Datei einer anzuwählenden Gruppe, während die Ctrl-Taste zur Erweiterung der bisher selektierten Dateien herhalten muss. Kopieren kann man die markierten Dateien, indem man sie einfach mit gedrückter Maustaste zum gewünschten Zielort bewegt. Im Zuge der Neugestaltung zeigt die Shell nun die Bildschirmseite `Programme starten´ gleichzeitig mit der Dateiverwaltung an. Außerdem offenbart sie besonders VGA-Benutzern viel Gestaltungsfreiheit in Sachen Schrift und Grafikauflösung.

Als äußerst nützlich erweist sich weiterhin die neue Eigenschaft der Shell, beim Einlesen des Verzeichnisbaums nicht mehr den Benutzer völlig zu ignorieren. Diese Eigenbrötelei war bisher vor allem dann sehr ärgerlich, wenn man die Shell startete, und das aktuelle Laufwerk vollgestopft war mit Dateien, man aber eigentlich mit einem anderen Laufwerk arbeiten wollte. Anstatt Kaffeetrinkend das Ende dieser Operation abwarten zu müssen, kann man nun schon in den Pulldown-Menüs umherwandern und Einstellungen vornehmen oder einfach das Laufwerk wechseln.

Ebenfalls neu eingeführt wurde in der Shell ein Task-Switcher, der einen fliegenden Wechsel zwischen mehreren Programmen ermöglicht, ohne diese dazu jeweils beenden zu müssen. Mit Hilfe eines wählbaren Hot-Keys (Alt-Esc, Alt-Tab oder Ctrl-Esc) gelangt der Benutzer zurück zur Shell, von wo aus er dann ein weiteres Programm starten oder zu einer bereits geladenen Applikation wechseln kann. Allerdings handelt es sich hierbei nicht um Multitasking, da DOS bei einem Wechsel jeweils (fast) den kompletten Speicherinhalt in Form eines Schnappschusses auf die Platte auslagert. Ein Weiterarbeiten der Software im Hintergrund ist somit ausgeschlossen.

Dafür läuft diese Technik aber problemlos auf einem XT, kein zusätzlicher Speicherchip ist dafür nötig. Einzig etliche freie Kilobytes auf der Festplatte sollten allerdings verfügbar sein. Der Task-Switcher hingegen beansprucht für seine Arbeit circa 35 bis 40 KByte RAM. Dieser Wert erscheint zwar im ersten Augenblick sehr hoch, jedoch versteckt sich dahinter das neue `DOS Task Switcher API´. Nach neuester Sitte (DPMI) ziert dieses API die niedrige Versionsnummer 0.8, die somit den Trend weg von den hohen Versionsnummern klar unterstreicht. Möglicherweise will Microsoft von vornherein einer möglichen Kritik am API mit dem Hinweis auf das `Planungsstadium´ begegnen - bekanntermaßen hält nichts dauerhafter als ein Provisorium ...

Das DOS-Task-Switcher API nimmt sich der Probleme an, die entstehen, wenn Software nicht jederzeit ausgelagert werden darf oder gar immer über das aktuell laufende Programm informiert sein muss. In erstere Kategorie fällt zum Beispiel DFÜ-Software oder Emulations-Software zur Anbindung an Mainframes, die sich nicht ohne weiteres unterbrechen lässt - ansonsten bräche die Verbindung zusammen und Datenverlust wäre die Folge. Die zweite Kategorie bilden vornehmlich Netzwerk-Shells, die für die Emulation von Netzwerk-Laufwerken zuständig sind. Bei einem Wechsel des Programms muss die Netzwerk-Shell zugleich auf die entsprechenden angemeldeten Netzwerk-Laufwerke umschalten. Ansonsten entstünde möglicherweise ein herrliches Chaos, wenn einem früher angelaufenen Programm durch den Start einer weiteren Applikation die Netzwerk-Laufwerke unter den Füßen weggezogen werden.

Alle Programme, die vom Task-Switcher Bescheid bekommen wollen, hängen sich dazu in den Multiplex-Interrupt 2Fh ein. Dort warten sie dann die Aufforderung des Task-Switchers ab, sich zu melden. Das letzte Programm im INT 2Fh gibt dazu einen Zeiger auf einen Datenblock zurück, der unter anderem die Adresse enthält, an die Mitteilungen zu verschicken sind. Das nächste Programm im INT 2Fh hängt nun seinen Datenblock davor, so dass eine Liste mit allen `Nachrichtenempfängern´ entsteht. An diese schickt der Task-Switcher der Reihe nach immer dann eine Mitteilung, sobald der Anwender eine neue Sitzung (`Session´) startet, eine alte beendet oder zwischen Sitzungen wechselt. Die von diesen Vorfällen benachrichtigte Software kann dann unter Umständen ihr Veto einlegen und die geplante Aktion damit abblasen.

Coda

Ende Juni soll die neue DOS-Fassung erhältlich sein. Aber zunächst gelten die altbekannten Modalitäten.Nur zusammen mit einem neuen System kann man MSDOS 5.0 erstehen. Erst im Juli sollen dann auch Besitzer einer älteren DOS-Version in den Genuss der neuen kommen.Microsoft bietet erstmalig ein `DOS-Update´ an.Einzige Voraussetzung ist eine der Vorgänger-Versionen ab 2.11; die `Update´-Disketten allein sind nicht bootfähig. Ein Nachweis, dass man bereits ein DOS erworben hat, ist nicht nötig - kein Wunder, denn der Preis für das `Update´ entspricht dem der Vollversion. Einziger Unterschied zwischen den beiden Angeboten ist das Installationsprogramm beim `Update´, das beim Systemwechsel ohne Neuformatieren der Platte auskommt.

Trotz aller Neuerungen bleiben Wünsche offen: So arbeitet die erweiterte Speicherverwaltung nur auf Systemen mit 80386-Prozessor - zumindest liefert Microsoft nur dafür die notwendigen Treiber. Wer etwa einen 286er mit NEAT-Chipsatz hat, muss seine Speicherlücken weiterhin mit Fremdprodukten füllen - aber wenn auch der fünfte Anlauf nicht der Weisheit letzter Schluss ist, so stellt er doch einen großen Schritt in die richtige Richtung dar. (ps)

Literatur

[1] Harald Albrecht, Odyssee im Adressraum, c't 11/89, S. 336

[2] Ralf Preller, Jenseits der Adapter, c't 11/88, S. 140

[3] Martin Ernst, Treiber verschiebt Treiber, c't 8/89, S. 130

[4] Harald Albrecht, Rezepte für den Protected Mode, c't 2/91, S. 285