Oberer Speicherbereich – Wikipedia
In der DOS-Speicherverwaltung wird die oberer Speicherbereich ((UMA) bezieht sich auf den Speicher zwischen den Adressen 640 KB und 1024 KB (0xA0000–0xFFFFF) in einem IBM PC oder einem kompatiblen Computer. IBM hat die obersten 384 KB des 1024-KB-Adressraums der 8088-CPU für BIOS-ROM, Video-BIOS, Options-ROMs, Video-RAM, RAM auf Peripheriegeräten, speicherabgebildete E / A und veraltetes ROM-BASIC reserviert.[1]
Selbst mit Video-RAM, ROM-BIOS, Video-BIOS, Options-ROMs und E / A-Ports für Peripheriegeräte wurde ein Großteil dieses Adressraums von 384 KB nicht verwendet. Als die Speicherbeschränkung von 640 KB immer mehr zu einem Hindernis wurde, wurden Techniken gefunden, um die leeren Bereiche mit RAM zu füllen. Diese Bereiche wurden als bezeichnet obere Speicherblöcke ((UMBs).
Die nächste Stufe in der Entwicklung von DOS bestand darin, dass das Betriebssystem obere Speicherblöcke (UMBs) und den hohen Speicherbereich (HMA) verwendete. Dies geschah mit der Veröffentlichung von DR DOS 5.0 im Jahr 1990.[2] Der in DR DOS integrierte Speichermanager EMM386.EXE könnte die meisten Grundfunktionen von QEMM und vergleichbaren Programmen ausführen.
Der Vorteil von DR DOS 5.0 gegenüber der Kombination eines älteren DOS plus QEMM bestand darin, dass der DR DOS-Kernel selbst und fast alle seine Datenstrukturen in einen hohen Speicher geladen werden konnten. Dies ging praktisch alle Der Basisspeicher ist frei und ermöglicht Konfigurationen mit bis zu 620 KB von 640 KB.
Die Konfiguration erfolgte nicht automatisch – freie UMBs mussten von Hand identifiziert und manuell in die Zeile aufgenommen werden, in der EMM386 von CONFIG.SYS geladen wurde, und dann mussten Treiber usw. von CONFIG.SYS und AUTOEXEC.BAT manuell in UMBs geladen werden. Diese Konfiguration war kein trivialer Prozess. Da dieses Programm durch das Installationsprogramm von QEMM weitgehend automatisiert wurde, blieb es auf dem Markt bestehen. In der Tat funktionierte es gut mit DR DOS ‘eigener HMA- und UMB-Unterstützung und wurde zu einem der meistverkauften Dienstprogramme für den PC.
Diese Funktionalität wurde von Microsoft mit der Veröffentlichung von MS-DOS 5.0 im Juni 1991 kopiert.[2] Schließlich wurden noch mehr DOS-Datenstrukturen aus dem herkömmlichen Speicher verschoben, sodass bis zu 631 KB von 640 KB frei bleiben konnten. Ab Version 6.0 von MS-DOS enthielt Microsoft sogar ein Programm namens MEMMAKER, mit dem der herkömmliche Speicher automatisch optimiert wurde, indem TSR-Programme in den oberen Speicher verschoben wurden.
In den frühen neunziger Jahren wurde die manuelle Optimierung der DOS-Speicherzuordnung zu einer hoch geschätzten Fähigkeit, die es den größten Anwendungen ermöglichte, selbst auf den komplexesten PC-Konfigurationen ausgeführt zu werden. Die Technik bestand darin, zunächst so viele UMBs wie möglich zu erstellen, einschließlich der Neuzuordnung zugewiesener, aber nicht verwendeter Speicherblöcke, z. B. des monochromen Anzeigebereichs auf Farbmaschinen. Dann mussten die vielen Unterkomponenten von DOS in der richtigen Reihenfolge in diese UMBs geladen werden, um die Speicherblöcke so effizient wie möglich zu nutzen. Einige TSR-Programme benötigten beim Laden zusätzlichen Speicher, der nach Abschluss des Ladevorgangs wieder freigegeben wurde. Glücklicherweise gab es nur wenige Abhängigkeiten zwischen diesen Modulen, so dass es möglich war, sie in nahezu beliebiger Reihenfolge zu laden. Ausnahmen waren, dass zum erfolgreichen Zwischenspeichern von CD-ROMs die meisten Festplatten-Caches nach CD-ROM-Treibern geladen werden mussten und dass die Module der meisten Netzwerkstapel in einer bestimmten Reihenfolge geladen werden mussten, wobei im Wesentlichen schrittweise durch die Schichten der OSI-Modell.
Eine grundlegende und dennoch effektive Methode zur Optimierung des konventionellen Speichers bestand darin, HIMEM.SYS als Gerät zu laden und anschließend EMM386.EXE als Gerät mit der Option “RAM AUTO” zu laden, die den Zugriff auf die UMA ermöglicht, indem Gerätetreiber als Gerätehöhe geladen werden. Diese Methode lädt die grundlegenden Speichermanager effektiv in den herkömmlichen Speicher und danach alles andere in die UMA. Herkömmliche Speicher-Vielfraß-Programme wie MSCDEX könnten auf ähnliche Weise auch in die UMA geladen werden, wodurch eine große Menge an herkömmlichem Speicher frei wird.
Windows[edit]
Die zunehmende Beliebtheit von Windows 3.0 machte die Notwendigkeit des oberen Speicherbereichs weniger relevant, da Windows-Anwendungen nicht direkt von den Basisspeicherbeschränkungen von DOS betroffen waren, DOS-Programme, die unter Windows ausgeführt wurden (wobei Windows selbst als Multitasking-Manager fungierte), dies jedoch weiterhin waren eingeschränkt. Mit der Veröffentlichung von Windows 95 wurde es immer weniger relevant, da diese Windows-Version einen Großteil der Funktionen der DOS-Gerätetreiber für unter Windows ausgeführte DOS-Anwendungen wie CD-, Netzwerk- und Soundunterstützung bereitstellt. Die Speicherzuordnung von Windows 95-DOS-Boxen wurde automatisch optimiert. In dieser Umgebung konnten jedoch nicht alle DOS-Programme ausgeführt werden. Insbesondere Programme, die versuchten, direkt vom realen in den geschützten Modus zu wechseln, funktionierten nicht, da dies im virtuellen 8086-Modus, in dem sie ausgeführt wurden, nicht zulässig war. Dieser Punkt wird jetzt von x86-Virtualisierungstechnologien wie Intel VT-x (Vanderpool) behandelt ) und AMD-V (Pacifica). Programme, die versucht haben, den Wechsel mithilfe der VCPI-API (Virtual Control Program Interface) durchzuführen (die eingeführt wurde, um DOS-Programmen, die einen geschützten Modus benötigen, den Zugriff aus dem von einem Speichermanager eingerichteten virtuellen 8086-Modus zu ermöglichen, wie oben beschrieben), haben dies nicht getan Funktioniert nicht unter Windows 95. Es wurde nur die DPMI-API (DOS Protected Mode Interface) zum Umschalten in den geschützten Modus unterstützt.
Implementierung[edit]
Virtueller 8086-Modus[edit]
Obere Speicherblöcke können erstellt werden, indem der erweiterte Speicher im virtuellen 8086-Modus dem oberen Speicherbereich zugeordnet wird. Dies ähnelt der Emulation von erweitertem Speicher mithilfe von erweitertem Speicher, sodass diese Methode zum Bereitstellen von oberen Speicherblöcken normalerweise vom erweiterten Speichermanager (z. B. EMM386) bereitgestellt wird. Die Anwendungsprogrammierschnittstelle zur Verwaltung der oberen Speicherblöcke ist in der angegeben eXtended Memory-Spezifikation.
Schatten-RAM[edit]
Auf vielen Systemen, einschließlich moderner, ist es möglich, Speicher, der für das Abschatten des Erweiterungskarten-ROM reserviert ist, als oberen Speicher zu verwenden. Viele Chipsätze reservieren zu diesem Zweck bis zu 384 KB RAM. Da dieser RAM im Allgemeinen nicht verwendet wird, kann er mit einem benutzerdefinierten Gerätetreiber wie UMBPCI als oberer Speicher im Realmodus verwendet werden.[3]
IBM XT[edit]
Auf IBM XT-Computern war es möglich, dem Motherboard mehr Speicher hinzuzufügen und ein benutzerdefiniertes Adressdecoder-PROM zu verwenden, um es im oberen Speicherbereich anzuzeigen.[4] Wie bei dem oben beschriebenen oberen 386-basierten Speicher kann der zusätzliche RAM zum Laden von TSR-Dateien oder als RAM-Disk verwendet werden.
Mit der AllCard, einer zusätzlichen Speicherverwaltungseinheit für Computer der XT-Klasse, konnte normaler Speicher dem Adressbereich 0xA0000-EFFFF zugeordnet werden, was für DOS-Programme bis zu 952 KB ergab. Programme wie Lotus 1-2-3, die direkt auf den Videospeicher zugegriffen haben, mussten gepatcht werden, um dieses Speicherlayout zu handhaben. Daher wurde die 640-KB-Barriere auf Kosten der Softwarekompatibilität entfernt. Diese Verwendung des oberen Speicherbereichs unterscheidet sich von der Verwendung von oberen Speicherblöcken, die zum Freigeben von herkömmlichem Speicher verwendet wurden, indem Gerätetreiber und TSRs in die oberen 384 KB des 1-MB-Adressraums verschoben wurden, jedoch die Menge des adressierbaren Speichers (640 KB) belassen wurden ) intakt.
Siehe auch[edit]
Verweise[edit]
- ^ “Speicherzuordnung (x86) – OSDev Wiki”. wiki.osdev.org. Abgerufen 2020-12-20.
- ^ ein b Dryfoos, Mike, hrsg. (1991-09-18) [1991-07-19]. “Post-Mortem-Entwicklungsbericht für MS-DOS 5.0” (PDF) (Post als Gerichtsdokument). Microsoft. p. 10. MS-PCA1179169 (MS-PCA1179159-MS-PCA1179191). MS7020988 (MS7020978-MS7021010). Depo. Ex. 1109. Kommt gegen das Exponat 3473 des Microsoft-Klägers. CA.No.2: 96CV645B Exponat 477 des Klägers. Archiviert (PDF) vom Original am 02.04.2019. Abgerufen 2019-07-22.
[…] Einer der wichtigsten Anreize für das Hinzufügen von Funktionen war der Wettbewerbsdruck durch DRDOS 5.0, von dem wir im Frühjahr 1990 erstmals erfahren haben. Der DRDOS-Funktionsumfang führte dazu, dass wir UMB-Unterstützung, Task-Swapping und Undelete hinzufügten. […] Beträchtliche Aufmerksamkeit des Managements des Teams wurde auf neue Funktionen wie Dateiübertragungssoftware, Wiederherstellen und Netzwerkinstallation gelenkt […] Schließlich erreichte diese Situation Ende Juli 1990 einen Krisenpunkt, und unter der Leitung von BradS verbrachte das Management des Teams eine mühsame Reihe von Besprechungen, in denen ein Zeitplan und ein Prozess für den Abschluss des Projekts festgelegt wurden […]
(1 + 32 Seiten) - ^ “UMBPCI V3.89 – nicht der Hardware-UMB-Treiber des Magazins für DOS und Win95 / 98”. Archiviert vom Original am 30.12.2019. Abgerufen 2020-02-07.
- ^ Atkinson, Cy (2001). “Was ist High Memory, warum interessiert es mich und wie kann ich es verwenden?”. San Jose, CA, USA. Archiviert vom Original am 05.10.2018. Abgerufen 2020-02-07.
Recent Comments