Einrichtung DOS 7.1

IBM DOS Speicheraufteilung

Die DOS Speicheraufteilung ist nicht unkompliziert. Die Historie begründet, wie es dazu kam: der IBM-PC war 1981 als Konkurrenz zu etablierten Mikrocomputern konzipiert worden, die auf dem 8-Bit Betriebssystem CP/M basierten (Osborne, Kaypro u.v.m.). CP/M-Maschinen konnten prinzipbedingt nur 64KiB Hauptspeicher verwalten. Daher ging man bei IBM davon aus, das in einem ‘Single Task’- Betriebssystem wie DOS der residente Teil des Betriebssystems (command.com) und eine gestartete Anwendung zusammen niemals mehr als 640KiB Speicher benötigen würde. So kam es zur Einführung der 640KiB Speichergrenze für DOS, obwohl man mit der verwendeten 16-Bit 8086/8088 CPU bis zu 1024KiB hätte adressieren können. Es war anfangs tatsächlich so, das man bereits mit 64KiB RAM ganz passabel arbeiten konnte. Der erste IBM PC 5150 wurde in der Minimal-Konfiguration mit nur 16KiB RAM ausgeliefert, wenn man DOS verwenden wollte mit 64KiB. Msdos.sys, io.sys und der speicheresistente command.com der DOS-Versionen 1.x benötigten nur etwas mehr als 12KiB im Speicher, 52KiB blieben übrig für die Anwendung.

Und das reichte den ersten Versionen von z.B. Wordstar oder dBase II. Diese wurden einfach von CP/M auf DOS umgesetzt und mussten vorher auch unter CP/M mit 64KiB RAM auskommen. Der Nachfolger XT besaß bereits standardmäßig 128KiB RAM, wurde jedoch meist mit “üppigen” 256KiB bestellt.

Ab Mitte der 1980iger wurden die Ansprüche der Anwender an das Betriebssystem DOS immer höher, denn die Anwendungen erhielten mit jeder neuen Version zusätzliche speicherfressende Features. Speicherresidente Programme (TSR, z.B. Borland’s Sidekick) und Treiber für zusätzliche Adapter (z.B. Sound- und Netzwerkkarten) verursachten zusätzlichen Speicherbedarf, und so wurde die 640 KiB Speichergrenze wider Erwarten doch zum Problem. MS, IBM und andere findige Entwickler erkannten dies und begaben sich auf die Suche nach zusätzlichem Speicher, um das Problem zu lösen oder wenigstens zu mildern. Die Nachfolge-CPU Intel 80286 kam im IBM AT 5170 zum Einsatz und konnte bis zu 16MiB Speicher ansprechen. Um kompatibel zur Vorgänger-CPU zu bleiben, allerdings nur im sogenannten Protected Mode. Normalerweise lief der 80286 unter DOS aber im “Real Mode” und verhielt sich dann wie ein höher getakteter 8088/8086. Wurde die CPU von einer Anwendung in den “Protected Mode” geschaltet, dann bestand die Möglichkeit, nicht nur Speicher oberhalb der 1MiB Grenze zu adressieren sondern auch die 384 KiB zu nutzen, die zwischen 640 KiB (ab 0xA000) und unterhalb 1MB lag. Dieser Speicherbereich war für das BIOS des IBM PC, das BIOS von Adapterkarten und den Bildschirmspeicher vorgesehen. Der benötigte Speicherbereich für diese Komponenten musste noch unter der 1MiB-Grenze liegen, damit die 80xx-CPU diesen auch adressieren konnte. In den meisten Konfigurationen wurden diese 384KiB aber nur teilweise benötigt. So bot sich die Möglichkeit, in die ungenutzten Bereiche zumindest TSR- und Treiberprogramme auszulagern, um die wertvollen 640KiB DOS Speicher weitgehend für die eigentlichen Anwendungen freizuhalten.

Durch diese Tricks wurde die Konfiguration der Speicherverwaltung von DOS im Laufe der Zeit recht komplex und es gibt es ziemlich viele Begriffe, deren Bedeutungen verstanden werden wollen.

Kurze Zusammenfassung bis hierher: unter 640KiB, das ist der “konventionelle Speicher”, hier hat DOS die vollständige Kontrolle. Den Bereich über 640KiB (0xA0000) bis zur 1024KiB Grenze (0xF0000) könnte DOS zwar noch adressieren, aber hier gibt es – auch bei Rechnern, die mit 1MB RAM und mehr ausgestattet sind – normalerweise kein durch DOS ansprechbares RAM. Dieser Adressbereich wird als UMA (Upper Memory Area) bezeichnet und ist reserviert: der Bildschirmspeicher der Grafikkarte, das eigene BIOS von Adaptern (z.B. SCSI-Controller, Netzwerkkarte) und das PC-BIOS selbst müssen – wie bereits erwähnt – zwingend in einen für DOS adressierbaren Adressbereich unter der 1 MB – Grenze eingeblendet (gemapped) werden.

Extended Memory

Damit DOS (ab der Version 5.0) auf RAM jenseits der 1024KiB Grenze zugreifen kann, muss eine CPU vom Real Mode (der Standard-Modus, in dem DOS normalerweise läuft) in den sogenannten Protected Mode umgeschaltet werden. Wie erwähnt gibt es diesen Modus seit dem 80286, in einer pratikableren Implementierung erst ab dem i386. Um die freien Bereiche der UMA als RAM nutzen zu können benötigt man reales RAM, das dort eingeblendet werden kann und Treiberprogramme wie z.B. EMM386, 386Max, Qemm oder UMBPCI. Alle benutzen den “Protected Mode” und können so auf realen Speicher oberhalb der 1MB Grenze (Extended Memory) zugreifen, um in den nicht belegten Bereichen der UMA (UMB, Upper Memory Blocks) weiteren für DOS-Programme adressierbaren Speicher einzublenden. Dazu muss der Bereich über 1MiB (Extended Memory) aber vorher durch einen weiteren Treiber – im Normalfall HIMEM.SYS – zugänglich gemacht werden. HIMEM.SYS stellt ihn nach der Extended Memory Specification (XMS) zur Verfügung und übernimmt die Verwaltung des Zugriffs der einzelnen Programme. XMS-Speicher kann von DOS Programmen neueren Datums, die auf DPMI (‘DOS Protected Mode Interface’) basieren, auch direkt benutzt werden.

Die nachfolgende Speicheraufteilung ist nur beispielhaft, da sie abhängig von der verwendeten Grafikkarte (CGA, EGA, Hercules, VGA), dem Vorhandensein von Zusatzkarten mit eigenem BIOS oder dem Computermodell ist (die IBM PS/2 Modelle belegen mit ihrem BIOS den oberen Teil der UMA).

Das war noch nicht alles, seit dem Erscheinen des Intel 80286 und einer hier vorhandenen zusätzliche Adressleitung (A20) gibt es auch noch die HMA (High Memory Area), mit der die ersten 64 KiB des Speichers oberhalb der der 1MiB-Grenze durch einen Trick als adressierbarer Speicher für DOS-Programme zur Verfügung gestellt werden können. Das funktioniert nicht nur im Protected Mode des 80286, sondern auch im Real Mode. Erst ab der Version 5.0 war DOS in der Lage, den eigenen Systemkern in die HMA zu verlagern (DOS=HIGH) und damit viel konventionellen Speicher freizuräumen.

Treiberinstallation in CONFIG.SYS

Bemerkung: verständlicherweise kann nicht jeder Parameter eines jeden Treibers kann hier beschrieben werden

• MO-Laufwerk: Hier wird der Treiber benutzt, der auf der originalen Fujitsu-Diskette zu finden war (MODISKAP.SYS). Der Treiber sollte aber auch im Internet zu finden sein.
• USB Unterstützung. Die “Motto Hairu” Treiber USBASPI.SYS (ohne weitere Parameter, eine USB-Floppy wird nicht benötigt) und DI1000DD.SYS. Diese Treiber müssen im Internet bezogen werden. Ein USB Laufwerk muss übrigens bereits vor dem Booten angeschlossen sein, damit der Treiber es erkennen kann. Ist eben kein Plug&Play, wie man es von Windows her kennt. USB Sticks und Festplatten funktionieren nur bis zu einer Größe bis ca. 120 GB. Speicherkarten, Zip-Laufwerke und – mit entsprechendem Parameter – USB Floppy Laufwerke gehen auch, letzeres sogar bootfähig. Ist kein Laufwerk beim Booten angeschlossen, wird der Treiber nicht geladen und verbraucht somit auch kein RAM. Den Treiber und vieles andere mehr finden Sie auf Hiren&Pankays Homepage.
• NANSI.SYS (schönere Prompts, ein bisschen Farbe in Batchdateien, DOS-Befehle auf Tastendruck). NANSI.SYS ist dem Standart ANSI.SYS nicht nur deswegen zu bevorzugen, weil er nur 3KiB statt 4KiB RAM beansprucht, sondern weil er wesenlich schneller ist.
• EMM386.EXE tauschen wir gegen UMBPCI.SYS. Wir brauchen kein EMS, und dieser Speichermanager verbraucht viel weniger konventionellen Speicher, auch weil HIMEM.SYS nicht mehr benötigt wird. Abhängig vom Chipsatz ihres Mainboards kann es bei Verwendung von UMBPCI.SYS notwendig sein, zusätzlich den Treiber LOWDMA.SYS zu installieren. Dieser darf nicht Fall hochgeladen werden. Bei unserem Mainboard mit Intel Chipsatz 440BX muss er installiert sein, sonst gibt es Probleme mit Diskettenzugriffen, wenn z.B. DOSLFN hochgeladen wird und in den Speicher unter E000h rutscht. Dieser Bereich ist beim verwendeten Board nicht ISA-DMA fähig. Lesen Sie bei Verwendung zum besseren Verständnis von UMBPCI.SYS unbedingt die Seite von Uwe Sieber. Weitere Links mit Tipps zu den DOS-Konfigurationsdateien: www.deinmeister.de, www.madsenworld.dk
• IFSHLP.SYS, für spätere Netzwerkinstallation

Programme/TSR’s in der AUTOEXEC.BAT

• SMARTDRV.EXE beschleunigt den Dateizugriff erheblich. Allerdings haben wir uns für LBACache aus FreeDOS entschieden. Es braucht viel weniger Speicher als Smartdrive und ist wohl das modernste Cache-Programm, das man momentan für DOS finden kann. Die Pufferung für die Diskettenlaufwerke A und B kann abgeschaltet werden. LBACache werden 4 MiB Speicher zugeteilt, es ist ja genug Extended Memory vorhanden. Der Schreib-Cache sowie der Cache für Diskettenlaufwerke wird nicht eingeschaltet. Das Programm könnte auch über die config.sys eingebunden werden. 4MiB schneller Cache unter DOS, das macht sich effektiv bemerkbar! Weitere Cache-Programme: Norton Desktop beinhaltet nwcache2, PC Tools Desktop bringt pc-cache mit. Bestimmt keine schlechten Programme, aber mehr als 15 Jahre älter als LBACache. Das gleiche gilt für die Cache-Programme Hyperdisk 4.65 und Super.exe aus PC-Kwik 3.1. Alle können u.E. nicht mal mit Smartdrv aus DOS 7.1 mithalten. Da von den Letztgenannten nur Shareware vorhanden ist, wurden sie nach dem Testen wieder gelöscht.
  Tipp: mehr Cache-Speicher benötigt nicht nur mehr XMS, sondern aus Verwaltungsgründen auch mehr konventionellen Speicher bzw. wenn das Programm hochgeladen wird, auch mehr Speicher in den UMB’s.
  Tipp: Bei Verwendung eines Cache-Programms sollte man den Eintrag BUFFERS in der CONFIG.SYS auf 3 heruntersetzen, sonst wird zweimal gepuffert!
  Tipp: Wir empfehlen im Zusammenhang mit Flash-Speichern (DOM, SD, CF) gar keine Cache-Programme zu verwenden!
• VSHIELD: ein Virenscanner sollte permanent laufen. Wir haben die schlechte Erfahrung gemacht, das sich auch auf manchen Originaldisketten im Laufe der Jahre ein Bootsektor-Virus oder ähnliches eingenistet haben kann. Es gibt allerdings keine aktuellen Virenscanner, die noch unter DOS betreibbar sind. Das muss aber auch nicht sein. Die Viren, die hier vorkommen können, deckt ein Virenscanner von 1997 (McAfee 3.0 mit Virendefinitionen der Version 3.2.2) weitestgehend ab.

• Für das CD-ROM wird SHCDX33E verwendet. Er braucht wesentlich weniger Speicher als MSCDEX.
• KEYB.COM wird durch KBD.COM ersetzt. Das ist ein kleiner, allerdings nur deutscher Tastaturtreiber, der auch den Treiber COUNTRY.SYS in der CONFIG.SYS obsolet macht. Trotzdem sollte der Eintrag COUNTRY.SYS nicht entfernt werden, einige Programme benutzen diese Einstellungen (z.B. für das Anzeigeformat von Datum und Uhrzeit)
• CTMOUSE wird als Maustreiber eingesetzt. Er braucht wenig Speicher und kann mit allen Mäusen.
• Für die Ramdisk wird XMSDSK verwendet. Ihm werden 32 MB XMS-Speicher und der Laufwerksbuchstaben Z:. zugeteilt. Das ist ist üppig, aber komfortabel zum Entpacken von großen Archiv- und Installationsdateien. Einige DOS Programme bieten eine Einstellung für temporären Speicher. Der wird – wo möglich – auch auf Z: (der Laufwerksbuchstabe der RAM-Disk) gelegt.

Wenn diese Konfiguration gebootet wird, ohne irgendwas in UMB’s hochzuladen, dann bleiben nur noch ca. 560 KiB konventioneller Speicher übrig. Das Speicheroptimierungsprogramm MEMMAKER (Bestandteil von DOS 7.1) kann hier zwar helfen, Feintuning aber nicht ersetzen. Soll MEMMAKER eingesetzt werden, ist es übrigens besser, temporär EMM386 mit der Option NOEMS in der CONFIG.SYS wieder zu aktivieren. Wir ziehen manuelles Speichertuning vor:

• Dabei immer wichtig: eine DOS 7.1 Bootdiskette mit deutschem Tastaturtreiber und einem ASCII-Editor (z.B. edit.com) oder z.B. Volkov Commander! Falls was schiefgeht und der Rechner nicht mehr hochfährt, kann man von der Diskette booten und die Konfigurationsdateien bearbeiten. Gute Praxis ist, vor dem Laden der verschiedenen Treiber und Programme ein PAUSE-Statement einzubauen, damit man besser feststellen kann, wo es hakt. Es gibt übrigens auch die Möglichkeit, in der CONFIG.SYS den Ablauf anzuhalten: suchen Sie im Netz nach PAUSE.SYS.
• CONFIG.SYS: alle hochladbaren Treiber mit DEVICEHIGH versuchen, in den UMB’s unterzubringen.
• AUTOEXEC.BAT: alle Programme mit LOADHIGH hochladen. Ausnahmen: McAfee’s VSHIELD und XMSDSK, die laden sich ohne LOADHIGH automatisch hoch.
• Danach sollte “mem /c /p” schon mehr freien Speicher anzeigen.
• Notieren Sie sich die Größen, die die Programme im Speicher belegen, denn diese Werte sind für eine Optimierung relevant. mem /c /p zeigt das ja an wie auch den noch verfügbaren Speicher in der UMA. Sie können die Ausgabe von “mem /c” auch in eine Datei umleiten, dann ersparen Sie sich das Aufschreiben: mem /c >c:mem.txt.
• Grundsätzlich ist es empfehlenswert, die Programme mit dem größten Speicherbedarf soweit möglich zuerst zu laden. In der CONFIG.SYS wie auch in der AUTOEXEC.BAT. Das liegt daran, das sich die Treiber und Programme immer den größten freien UMB suchen. Werden kleine Treiber oder Programme/TSR’s zuerst geladen, belegen sie immer den größten vorhandenen UMB, auch wenn sie in einen kleineren passen würden. Größere Treiber und Programme sind dann vielleicht nicht mehr komplett in einem UMB unterzubringen und laden sich dann in den konventionellen Speicher. Wichtig ist aber, die größeren Programme/Treiber in den UMB’s unterzubringen und wenn’s dann nicht mehr reicht, ein paar kleinere im konventionellen Speicher zu haben. Es ist ein Geduldsspiel mit vielen Bootvorgängen. Zugegeben, FreeDOS macht das besser. Tipp: googel’n Sie Optimizing your Use of Upper Memory Blocks. Sie müssten bei Microsoft einen Artikel finden, der einen interessanten Absatz enthält: Finding the best Load Order. Wir haben unsere 628KiB freien konventionellen Speicher nur über die Reihenfolge hingekriegt.
• Es gibt natürlich noch die Möglichkeit, einzelne Programme gezielt in bestimmte UMB’s zu laden. Wird bei DEVICEHIGH oder LOADHIGH beispielweise der Parameter /L:1 angegeben, wird versucht das Programm in diesen UMB abzulegen. MemMaker macht das so. Wenn man hier manuell vorgeht sollte man aber Bescheid wissen welche UMB’s in welcher Größe zur Verfügung stehen.
• Optimierte und funktionierende Konfigurationsdateien immer sichern. Eine spätere Programminstallation kann den ganzen schönen Feinschliff über den Haufen werfen. Ausserdem ist man froh, noch Konfigurationsdateien zu haben, mit denen man nicht mehr funktionierende schnell wieder ersetzen kann, falls der Rechner mal während des Bootens stehenbleibt und man von Diskette booten muß.

Am Ende sollten mindestens 620KiB freier Speicher vorhanden sein, aber das hängt natürlich von den benötigten Treibern und TSR-Programmen und der verbauten Hardware ab. In der beschriebenen Konfiguration sind es 629KiB, wenn ein USB Laufwerk angeschlossen und VSHIELD resident geladen ist. Das ist u.E. das Maximum, das mit DOS 7.1 möglich ist.

Die derzeitige CONFIG.SYS (mit Kommentaren)

Die derzeitige AUTOEXEC:BAT (mit Kommentaren)

Anmerkungen:

• Warum NET START aufgerufen wird, aber keine weiteren Netzwerktreiber eingebunden werden, liegt nur an der späteren Installation von “Windows 3.11”. Wenn das nicht vorgesehen ist, dann bitte weglassen.
• Die SET und die PATH Anweisungen hängen natürlich von den installierten Programmen ab.
• Es wird auffallen, das zwar eine Soundkarte eingebaut ist, aber nicht installiert wird. Das liegt daran, das zum Abspielen von MP3’s mit MPXPlay keine entsprechende Treiberinstallation notwendig ist. Das Programm hat eine automatische Erkennung der Soundkarte. Wenn Sie DOS-Spiele einrichten, muß natürlich der Soundkarten-Treiber dauerhaft in der autoexec.bat installiert werden. In diesem Fall wäre auch bei unserer Konfiguration ein Umbau notwendig, wenn weiter so viel konventioneller Speicher frei bleiben soll.
• TM.BAT („TM -c80 -r34“) setzt den Textmode auf 34 Zeilen und 80 Spalten, Wir benutzen an diesem Rechner einen 17″ Monitor. Das Utility TM (Text Mode) zum Setzen des Textmodes auf VGA-Karten ist Freeware.
• Die ECHO‘s mit den ANSI-Farben sind nur eine Spielerei und können natürlich auch weggelassen werden. Das kryptische PROMPT sollte Sie ebenfalls nicht irritieren, ein einfaches PROMPT $P$G tut’s auch. Die von Batch-Datei “PRG.BAT” zeigt Infos zu anderen Batches an, mit denen verschiedene Programme gestartet werden.
• KILLER soll fehlerhafte Opcodes eliminieren. Wenn es bei einem Rechner Ärger macht: rauswerfen
• SHARE ist eigentlich nur bei Netzwerkbetrieb notwendig, kann ansonsten weggelassen werden. Dann werden ca. 5 KiB in den UMB’s frei, die man vielleicht für was anderes nötiger brauchen könnte. Da wir nachfolgend auch WfW 3.11 auf dem Rechner haben werden, ist die Installation empfehlenswert.
• VSHIELD ist die speicherresistente Variante des McAfee Virenscanners. Dadurch wird jede Diskette, die eingelegt automatisch untersucht. Die Erfahrung hat gezeigt, das ein Virenscanner beim Archivieren hunderter alter Disketten kein Luxus sondern Notwendigkeit ist. Durch die Abfrage mit CHOICE kann beim Booten das Laden von VSHIELD optional auch unterdrückt werden.

So sieht die Ausgabe von mem /c nach der Optimierung aus (mit USB-Laufwerk):

Es sind also noch knapp 3KiB in den UMB’s verfügbar. Das eine oder andere kleinere Programm oder Treiber wäre also schon noch unterzubringen.

Hier die Ausgabe von mi (diesen mem-Ersatz finden Sie auch auf der Seite von Uwe Sieber unter “Utilities”). mi zeigt die Speicherbereiche, in die Treiber und TSR-Programme hochgeladen wurden. Im Bereich zwischen 0xA0000 und 0xC7FFF liegt der Bildschirmspeicher und das BIOS der VGA-Karte, darüber die ersten UMB’s, beginnend mit USBASPI. In der Tabellenspalte “Unterer” sieht man die Treiber, die “konventionellen Speicher” belegen. Eine entsprechende Anzeige solcher Informationen können Sie aber auch mit mem /d /p erreichen.