Die DOS-Speicherverwaltung:
Diese Datei beschreibt die DOS-Speicherverwaltung nur sehr groben
Umrissen. Alles andere würde ein ganzes Buch füllen. Ich bitte also
um Entschuldigung, daß Sie keine Details finden.
Es gibt andere Dokumentationen zur DOS-Speicherverwaltung, z. B.
Wikipedia, siehe:
https://en.wikipedia.org/wiki/DOS_memory_management ODER:
https://blogsystem5.substack.com/p/from-0-to-1-mb-in-dos ODER:
Suchen Sie mit Ihrer Lieblingssuchmaschine nach "DOS Speicher-
verwaltung".
NORMALER unterer DOS Speicher:
Der NORMALE untere DOS-Speicher beträgt höchstens 640 kB.
Manchmal minus EBDA, was ein zusätzlicher BIOS-Datenbereich ist, siehe
die SWITCHES /E Option zum Manipulieren, wenn Sie wissen, was Sie tun.
UMB - upper memory blocks:
UMB, obere Speicherblöcke, sind der Bereich zwischen 640 kB
und 1 MB, auf den theoretisch alle 8086- oder neueren CPUs zugreifen
können; in der Praxis ist er jedoch für VGA-RAM, BIOS und ähnliches
reserviert. Treiber wie RDOSUMB, HIRAM oder URAM können auf verschie-
denen Mainboards in chipsatzabhängiger Weise normalen RAM in ungenutz-
ten Bereichen zwischen diesen aktivieren, und alle Arten von EMM386-
artigen Treibern können RAM in diesen Bereichen sichtbar machen, wenn
Sie eine 386- oder neuere CPU haben.
Manchmal hat UMB Einschränkungen, z. B. funktioniert es nicht mit
DMA für Disketten oder Festplatten. Mit den UMB-Treibern gebündelte
spezielle Treiber oder spezielle Optionen für EMM386 können verwendet
werden, die Einschränkungen zu umgehen oder zu versuchen, sie zu umge-
hen. Manchmal möchten Sie einfach vermeiden, bestimmte Festplatten-,
Netzwerk- oder USB-Treiber stattdessen in UMB zu laden. Sie können den
FreeDOS-Kernel mit DOSDATA=... anweisen, einige Datenstrukturen in
UMB zu verschieben, und Sie können DOS=... verwenden, um einige
andere Kernel-Dinge in UMB zu verschieben. Siehe auch FILESHIGH.
HMA - high memory area:
Der HMA High Memory-Bereich ist 64 kB groß und beginnt dort, wo
das erste MB endet. Sie können ihn auf 286er-CPUs oder neueren ver-
wenden, normalerweise indem Sie HIMEM oder ähnliche Treiber
laden. Sie können DOS=... verwenden, um große Teile des Kernels
nach HMA zu verschieben.
Andere Treiber können den verbleibenden HMA-Speicherplatz verwenden,
aber dies ist in FreeDOS nicht so einfach möglich wie in anderen DOS-
Versionen. Siehe auch FILESHIGH. Da die Erreichbarkeit von HMA vom
berüchtigten A20-Adresszeilen-Gate abhängt, müssen Sie möglicherweise
HIMEM oder EMM386 helfen, dies richtig zu behandeln, wenn die
automatische Erkennung zu einer falschen A20-Behandlung geführt hat.
XMS - extended memory:
Der XMS-Erweiterungsspeicher ist das, was Ihnen HIMEM und ähnliche
Treiber bieten. Bitte beachten Sie, dass JEMMEX ein Treiber ist, der
sowohl EMM386 als auch HIMEM in einem einzigen Treiber enthält.
XMS sind Speicherbereiche, die der Treiber nach Bedarf in oder aus
dem DOS-Speicher (oder UMB, vielleicht sogar HMA) kopieren kann. Apps
im geschützten Modus können auch direkt auf XMS am ursprünglichen
Speicherort jenseits von 1 MB zugreifen, nachdem HIMEM angewiesen
wurde, Bereiche zu sperren, damit sie einen konstanten absoluten
Speicherort behalten. Sie benötigen 286, mit gängigen Treibern sogar
386 oder neuere CPUs, um XMS zu verwenden.
EMS - expanded memory area:
EMS-Erweiterungsspeicher ist das, was EMM386 Ihnen normalerweise bietet,
aber es gibt auch Chipsatz-abhängige Hardwaretreiber für bestimmte alte
Mainboards mit Hardware-EMS-Unterstützung und es gab Hardwareer-
weiterungskarten für EMS für wirklich alte Computer. So oder so be-
steht EMS aus ursprünglich 16 kB, später 4 kB großen Speicherstücken,
die Sie an Stellen unter 1 MB sichtbar machen (abbilden) können. Für
den 4 kB-Stil benötigen Sie EMS 4, der 16 kB-Stil ist EMS 3.2 und
letzterer ist auch darauf beschränkt, die 16 kB-Stücke in jedem Viertel
eines 64 kB großen Page Frames an einer Stelle sichtbar zu machen,
die ein Vielfaches von 64 kB sein muss.
Dieser Page Frame nimmt Platz weg, den Sie sonst für UMB verwenden
könnten, daher gibt es eine irreführend benannte NOEMS-Option für
Treiber im Stil von EMM386, die eigentlich bedeutet, dass Sie keinen
Page Frame benötigen. Sie können 4 kB immer noch verschiedenen Viel-
fachen von 4 kB innerhalb des ersten Megabyte zuordnen, wenn Sie EMS 4
verwenden, selbst wenn Ihr EMM386 im NOEMS-Modus ist und keinen festen
Page Frame hat. Da Sie den Speicher an anderen Stellen erscheinen
lassen, anstatt ihn tatsächlich zu kopieren, kann EMS schnell sein,
wenn Sie Speicherbereiche austauschen möchten, beispielsweise zum Ver-
walten von Bibliotheken oder Hintergrundmusikdaten in einem Spiel, in
Situationen, in denen Sie nicht einen bestimmten Teil Ihrer Daten ko-
pieren möchten, sondern eine ganze Teilmenge Ihrer Daten verfügbar
haben möchten, falls Sie sie verwenden möchten. XMS hingegen ist gut,
wenn Sie bereits wissen, welchen bestimmten Datenbereich Sie wohin
kopieren möchten, weil Sie dort nicht den zusätzlichen Schritt des
Zuordnens ausführen müssen.
VCPI ist eine Low-Level-Schnittstelle für EMM386, die eine Koexistenz
mit anderer Software im geschützten Modus ermöglicht, sodass auch
Speicherzuordnung und -zuweisung erforderlich sind. Außerhalb von
DOS-Extendern ist es meiner Meinung nach nicht sehr beliebt.
Beachten Sie, dass Windows in diesem Zusammenhang als DOS-Extender
bezeichnet werden kann.
DPMI ist eine Schnittstelle auf höherer Ebene zur Verwaltung des
Speichers in einem geschützten Moduskontext. Es ist so komfortabel,
dass der CWSDPMI DOS Extender im Grunde nur sicherstellt, dass Sie
DPMI erhalten, notfalls destilliert aus einer Reihe anderer (!)
Arten des Speicherzugriffs, die in reinem DOS verfügbar sind, da Apps,
die mit DJGPP und ähnlichen Compilern kompiliert wurden, grob gesagt,
bereits mit DPMI als DOS Extender gut zurechtkommen. Windows
stellt Apps auch DPMI zur Verfügung, aber beispielsweise nicht VCPI,
da letzteres zu niedrigstufig für eine reibungslose Koexistenz mit
Apps wäre, die es direkt verwenden.
DOS-Extender stellen sicher, dass Apps im geschützten Modus mehr als
1 MB Speicher verwenden können, der aus jeder geeigneten Speicherquelle
entnommen wird. Daher können sie sich stark darin unterscheiden, welche
Speichertypen sie unterstützen oder nicht.
Dies betrifft auch den INT15-Speicher, eine BIOS-basierte Methode zum
Zugriff auf Speicher über 1 MB, die für die meisten DOS-Anwendungen an-
sonsten nicht relevant ist, weil sie stattdessen lieber die DOS-spezi-
fischeren Speichertypen verwenden. INT15 ist also eher etwas Relevantes
für HIMEM und EMM386, die entweder zusammenarbeiten oder miteinander
koexistieren können. Im Allgemeinen bietet das BIOS eine Reihe ver-
schiedener Methoden, um herauszufinden, welcher Speicher und wo er für
welche Zwecke verfügbar ist, oft INT15-bezogen. Daher müssen DOS-
Speichertreiber wie HIMEM darauf achten, die neueste verfügbare
Untermethode abzufragen, und sie müssen möglicherweise Mehrdeutigkeiten
und Widersprüche auflösen, wenn das BIOS nicht richtig designed ist.
Bitte beachten Sie, dass sehr spezielle DOS-Extender es Apps auch
ermöglichen können, mehr als 4 GB RAM oder mehr als einen CPU-Kern zu
verwenden. Beides ist noch nicht weit verbreitet, daher sind die
meisten Implementierungen von HIMEM oder EMM386 auf 2 bis 4 GB nutz-
baren RAM beschränkt, selbst wenn Sie mehr installiert haben, da Dinge
wie Grafikspeicher oder MMIO-Bereiche und zusätzliches BIOS-Zeug usw.
einen Teil des Speichers innerhalb der ersten 4 GB blockieren. Insbe-
sondere Grafik-RAM-Fenster können bei moderner Grafikhardware recht
groß sein, und nur wenige Apps oder Treiber für DOS machen sich die
Mühe, 36- oder 64-Bit-Adressierung zu verwenden, um über die ersten
4 GB hinauszukommen. Sie können davon ausgehen, dass der System-RAM,
auf den Sie unterhalb von 4 GB nicht zugreifen können, weil der Grafik-
RAM den Adressraum verwendet, an einer Stelle oberhalb von 4 GB ver-
fügbar gemacht wird, sodass 64-Bit-fähige Treiber Ihren gesamten RAM
verwenden können. Dies ist ähnlich dem oben erwähnten UMB-Problem.
RAM, das vom BIOS oder von VGA-RAM abgedeckt ist und daher nicht für
UMB verfügbar ist, kann je von Ihrer Hardware und Ihren Treibern
manchmal dennoch an einer anderen Adresse für andere Zwecke wie EMS
verfügbar gemacht werden.
Kommentar:
(Kommentar von Rugxulo:)
8086 konnte 1 MB (konventioneller Speicher) adressieren, aber der IBM
PC (im Gegensatz zu den SCP-Boards) nutzte nur 640 KB (abzüglich OS-
Overhead) mit ROM-Daten (z. B. BIOS) in höheren Teilen. EMS mit Bank-
switching war optional, aber einige Leute (z. B. Jim Leonard) haben
physische Hardware-EMS, was ein paar zusätzliche MB ermöglicht.
XMS erforderte einen AT, also einen 286 auf einem 286-Mainboard. Der
286 konnte nur 16 MB adressieren (oder angeblich 1 GB virtuell, wenn
ich mich recht erinnere). Es fragmentierte etwas schlimmer als EMS.
EMM386 war optional, half aber dabei, alte EMS-Apps im V86-Modus zum
Laufen zu bringen.
VCPI (nur Ring 0, 386) war eine Obermenge davon und wurde vom Win 3.x-
Standardmodus (win.com /s) unterstützt, aber DPMI war insgesamt besser.
DPMI wurde ursprünglich 1990 für Windows 3.0 (Enhanced Mode) ent-
wickelt, wurde aber später standardisiert und auch anderswo verbreitet
(OS/2 2.1, Novell DOS 7). Leider unterstützten die meisten Leute nur
die 0.9-Spezifikation (normalerweise nur für 32-Bit-Anwendungen).
Borland unterstützte jedoch 16-Bit-DPMI. Nur um das klarzustellen:
Anders als Ring 0 32-Bit exklusives VCPI könnte DPMI auch Ring 3 und
entweder 286 oder 386 kompatibel sein. Ring 3 ist weniger anfällig
für Betriebssysteminstabilität.
Bei der Implementierung aller oben genannten Punkte gibt es verschie-
dene Fehler und Einschränkungen.
Tests sind wichtiger als die blinde Einhaltung von Spezifikationen.
(Kommentar von bretjohn:)
Welche Speichertypen Sie in FreeDOS beim Booten tatsächlich konfigu-
rieren müssen, hängt davon ab, welche Programme Sie ausführen möchten
und welche Art(en) von Speicher sie verwenden.
Siehe auch:
DOS=
DOSDATA=
DOS Extenders
DPMI
EMM386
EMS
FILESHIGH
HIMEM
HIRAM
HMA
JEMMEX
Normaler unterer DOS-Speicher
SWITCHES
UMB
VCPI
XMS
Copyright © 2024 Eric Auer, Hilfeversion 2024 von W. Spiegl.
Diese Datei ist abgeleitet vom FreeDOS Spezifikationen-HOWTO.
Vgl. auch die Datei H2Cpying bezüglich der Kopierbedingungen.