~2025-42954-99: /* Entstehungsgeschichte */ typo

2026-02-15T03:24:14Z

Entstehungsgeschichte: typo

Neue Seite

Die '''{{lang|en|High Memory Area}}''' (HMA, {{enS}} teils auch verkürzt ''{{lang|en|himem area}}''<ref>{{Literatur |Autor=Jim Seymour |Titel=Utilities: System Setup – The Inside Story; Setup and Configuration: Defining the Terms |Sammelwerk=[[PC Magazine]] |Band=10 |Nummer=6 |Verlag=[[Ziff Davis]] |Datum=1991-03-26 |Sprache=en |Seiten=311 |Fundstelle=Defining Terms; continued |Online={{Google Buch |BuchID=f7GkbOJrVekC |SeitenID=PT286}} |Zitat=''Himem area'' High memory area or HMA.}}</ref>) ist ein [[PC-kompatibles DOS#Speichertypen|Speichertyp]] von [[MS-DOS]] und dazu [[PC-kompatibles DOS|kompatiblen DOS]]-Varianten. Mit der HMA werden die ersten 65520 Byte oberhalb der 1-[[Mebibyte|MiB]]-Grenze bei [[x86-Architektur|x86]]-kompatiblen [[Mikroprozessor|Prozessor]]en ab dem [[Intel 80286]] im [[16-Bit-Architektur|16-Bit]]-Betriebsmodus ''{{lang|en|[[Real Mode]]}}'' verfügbar. Die deutsche Übersetzung ''hoher Speicherbereich'' ist inzwischen ungebräuchlich geworden. Ursprünglich eingeführt wurde dieser [[Programmiertrick|Hack]] unter der Bezeichnung '''HIMEM'''.<ref name="PC_Magazine_1990_9-10_HIMEM" />

== Entstehungsgeschichte ==
Der ursprüngliche [[IBM Personal Computer|IBM PC]] nutzte einen [[Intel 8088|8088]]-Prozessor, der nur einen Mebibyte an Speicher direkt adressieren kann. Dieser Betriebsmodus wird ab dem 80286 als {{enS|[[Real Mode]]}} bezeichnet, der durch den neuen Betriebsmodus ''{{lang|en|[[Protected Mode]]}}'' abgelöst werden sollte. Als Intel den 80286 entwarf, war noch nicht klar, welchen Erfolg die [[IBM-PC-kompatibler Computer#PC als Plattform|PC-Plattform]] mit dem darauf dominierenden Betriebssystem [[MS-DOS]] und [[PC DOS]] haben würde. Der ''{{lang|en|Protected Mode}}'' ist daher nicht mit der bestehenden Software kompatibel, die weiterhin den ''{{lang|en|Real Mode}}'' nutzte. In diesem laufen auch alle neueren [[x86-Prozessor]]en im 8086-kompatiblen Modus, in dem nur 1 MiB RAM direkt adressierbar bleibt.

Im 80286 können 16 MiB [[Arbeitsspeicher]] im ''{{lang|en|Protected Mode}}'' genutzt werden, ab dem [[Intel 80386|80386]] sind es 4 GiB (4096 MiB). Dieser Speicher liegt unter 8088/8086-kompatiblen reinen 16-Bit-Systemen wie anfangs [[PC-kompatibles DOS|PC-kompatiblem DOS]] allerdings brach, denn im ''{{lang|en|Real Mode}}'' kann nicht darauf zugegriffen werden. Erst mit der [[Extended Memory Specification]], kurz XMS, konnte dieser „Erweiterte Speicher“ auch unter 16-Bit-Betriebssystemen im ''{{lang|en|Real Mode}}'', allen voran DOS, genutzt werden.

Der HIMEM-Trick nutzt die Art und Weise aus, wie der ''{{lang|en|Real Mode}}'' ab dem 80286 emuliert wird. Der Zugriff auf den RAM wird dabei in [[Real Mode#Segmentregister|Segmente]] aufgeteilt, das sind 65536 einander überlappende Speicherseiten à 64 KiB. Beim 8088/8086 endet der Speicher bei 1 MiB (1024 KiB) und es kommt zu einem [[Arithmetischer Überlauf|Überlauf]], wenn Speicher über dieser Grenze angesprochen wird. Dieser Umstand wurde von vielen DOS-Programmen ausgenutzt, um sie schneller zu machen. Beim [[IBM Personal Computer/AT|PC/AT]] musste sich IBM daher einen Mechanismus ausdenken, damit sich auch der 286er wie der originale IBM PC verhält, und hat das [[A20-Gate]] eingeführt. Darüber kann die 21. Adressleitung („A20“, da von 0 gezählt wird) des Prozessors entweder maskiert (also dauerhaft auf 0 gehalten) werden, so dass ein Überlauf wie beim 8086/8088 auftritt, oder aber – bei „offenem“ A20-Gate – freigeschaltet sein, so dass der Zugriff auf den Speicher jenseits der 1-MiB-Grenze möglich wird.

Der darin definierte Speicherabschnitt liegt damit 64 kB, minus 16 Bytes, im [[Erweiterter Speicher|Erweiterten Speicherbereich]] oberhalb der 1-MB-Grenze des ''{{lang|en|Real Mode}}'', und wird vom 80286 und nachfolgenden Prozessoren auch korrekt angesprochen, während der Prozessor dennoch im ''{{lang|en|Real Mode}}'' verbleibt.

Dieser Programmiertrick findet sich unter anderem im [[Taskswitcher]] [[DESQview]] von [[Quarterdeck Office Systems|Quarterdeck]]. Microsoft griff dieselbe Technik mit [[Microsoft Windows 2.x|Windows 2.1]] auf, das erstmals mit [[#HIMEM.SYS|HIMEM.SYS]] ausgeliefert wurde.<ref name="PC_Magazine_1990_9-10_HIMEM" />

Unter [[PC-kompatibles DOS|DOS]] kann die HMA dazu genutzt werden, Teile von sich selbst in diesen Bereich zu verschieben, um mehr [[Konventioneller Speicher|Konventionellen Speicher]] für Programme zur Verfügung zu haben.<ref name="PC_Magazine_1990_9-10_HIMEM">{{Literatur |Autor=Barry Simon |Titel=Lab Notes – How to Get the Most From your System’s High DOS Memory |Sammelwerk=[[PC Magazine]] |Band=9 |Nummer=10 |Verlag=[[Ziff Davis]] |Datum=1990-05-29 |Sprache=en |Seiten=347 ff. |Fundstelle=HIMEM |ISBN= |Online={{Google Buch |BuchID=FK9cQfDtQZkC |SeitenID=PT352}} |Zitat=Microsoft did not invent HIMEM, as is usually supposed. It was used earlier by Quarterdeck’s ''DESQview'', though it became widely available only with the release of ''Microsoft Windows'' 2.10. HIMEM uses a mere 64K of available extended memory—or, to be more exact, it uses the first 64K (minus 16 bytes) of extended memory, the memory directly above 1MB. The very important thing about HIMEM is that this 64K is accessible in real mode and can be used without a DOS extender. One possible use for HIMEM is to allow DOS to locate some of itself there, thus freeing up additional memory below 640K for user programs. HIMEM actually depends on a bug in the same way the 286 emulates the 8086! In addition to breaking up memory into pages—16 nonoverlapping 64K chunks—the CPU thinks of memory as overlapping 64K chunks, called segments, which start every 16 bytes. Suppose the CPU tries to access one of those segments that starts very close to the top of the 1MB boundary. An 8086 will wrap around to very low memory, as shown in Figure 2. On an 80286, however, the address actually accessed is just ''above'' the 1MB boundary. This provides real-mode addressability to the first 64K (minus 16 bytes) of extended memory. It’s 16 bytes less than 64K because the last segment begins 16 bytes shy of the 1MB boundary. To overcome the emulation bug, IBM built special capabilities into the bus that force memory to wrap around, like an 8086/88, in real mode. What the HIMEM driver does is to ''undo'' this safeguard selectively, so that a program specially written to use that area can put code there. That is what ''Microsoft Windows'', ''DESQview'', ''Ventura Publisher'' and ''Carousel'' do.}}</ref>


== {{Anker|HIMEM.SYS|HIDOS.SYS}}HIMEM.SYS / HIDOS.SYS ==
{{Hauptartikel|HIMEM.SYS}}
Da MS-DOS-kompatibles DOS auf dem IBM PC ursprünglich nur das erste Mebibyte des Hauptspeichers verwaltete, treten Probleme auf, sobald mehr als ein Programm oder [[Gerätetreiber|Treiber]] die HMA nutzt. Um dieses Problem zu lösen, wurden in den Speichermanager <code>HIMEM.SYS</code>, der den Zugriff auf den [[Extended Memory Specification|Erweiterten Speicher]] regelt, Funktionen aufgenommen, die die Reservierung und Freigabe der HMA regeln.

== Nutzung der HMA ==
Ab [[DR DOS]] Version 5.0 (1990) und [[MS-DOS]] Version 5.0 (1991) ist DOS in der Lage, seinen eigenen Systemkern in die HMA zu verlagern, wenn {{Monospace|HIDOS.SYS}} bzw. {{Monospace|HIMEM.SYS}} geladen ist. Dies wird durch die Option <code>HIDOS=ON</code> bzw. <code>DOS=HIGH</code> in der Konfigurationsdatei {{Monospace|[[CONFIG.SYS]]}} erreicht. Damit wird weniger [[Konventioneller Speicher]], also Speicher unterhalb der 640-KiB-Grenze, vom DOS-Kern belegt, was bei der chronischen Speicherknappheit von DOS vorteilhaft ist.

Bei DR DOS kann nicht nur ein Teil des Systemkerns selbst in die HMA verschoben werden, sondern auch der residente Teil des Kommandozeileninterpreters {{Monospace|COMMAND.COM}} (mit [[Kommandozeilenparameter|Option]] <code>/MH</code>), Teile der Pufferverwaltung (<code>HIBUFFERS</code>) und ab DR DOS 6.0 auch einige Treiber und TSR-Programme, etwa {{Monospace|[[KEYB]]}}, {{Monospace|[[NLSFUNC]]}} und {{Monospace|[[SHARE.EXE|SHARE]]}} (jeweils mit Option <code>/MH</code>), wodurch weiterer Konventioneller Speicher für Treiber und Anwendungen frei wird.

Ab DR-DOS 7.02 erlaubt der [[Kommandozeilenparameter|Parameter]] <code>SIZE=xxxx</code> der Konfigurationsdirektive <code>SHELLHIGH=</code> eine Feineinstellung der Präallokation für den residenten Teil des [[Kommandozeilenprozessor]]s, womit insbesondere bei der Verwendung von alternativen Kommandozeilenprozessoren wie [[4DOS]] einer [[Speicherfragmentierung|Fragmentierung]] der HMA vorgebeugt werden kann (etwa mit <code>SHELLHIGH SIZE=20 c:\4dos.com ...</code> in der {{Monospace|CONFIG.SYS}}), so dass insgesamt noch mehr zusammenhängender freier Speicherplatz für HMA-fähige Treiber nutzbar wird.

Obwohl eine möglichst weitreichende Nutzung der HMA durch Treiber erstrebenswert ist, machen insgesamt nur vergleichsweise wenige Treiber davon Gebrauch und wenn, dann in der Regel nur exklusiv, ohne dass dann gleichzeitig auch noch Teile des Betriebssystems oder andere Treiber in die HMA hochgeladen werden könnten.

Da die Adressleitung A20 über das A20-Gate jederzeit von anderen laufenden Prozessen maskiert werden kann, und in dieser Zeit die HMA nicht erreichbar ist, müssen kleine Programmteile (sogenannte ''{{lang|en|stubs}}'') im Konventionellen Speicher verbleiben, um jederzeit angesprungen werden zu können. So wird sichergestellt, dass auch bei maskierter A20-Leitung jede Funktion erreichbar bleibt, da der Funktionsteil im Konventionellen Speicher (der ''{{lang|en|stub}}'') die Leitung temporär wieder aktiviert, bevor Code oder Daten in der HMA angesprungen werden. Deshalb können u. a. auch keine Interruptroutinen in die HMA ausgelagert werden. Auch der Aufruf von externen Unterroutinen (mit nicht immer vollständig bekannten Seiteneffekten durch [[TSR-Programm]]e) aus der HMA heraus oder die Unterbrechung durch Interrupts ist nicht unkritisch und erfordert besondere Vorsorgemaßnahmen in der Implementierung. Das „klassische“ PC-kompatible DOS im ''Real Mode'' stellt ein nur sehr rudimentäres API zum Ändern der A20-Leitung zur Verfügung, eine zentrale Kontrollinstanz für den Zustand jedoch nicht. Für ein einzelnes Programm kann sich dessen Zustand daher „scheinbar zufällig“ ändern. Für eine sichere Implementierung ist die Hochlademöglichkeit für viele Treiber, je nach Aufgabe, technisch zwar prinzipiell erreichbar, aber meist zu aufwendig in der Realisierung, nicht zuletzt um nicht sofort offensichtliche ''Race Conditions'' zu vermeiden. Erst 386-Speichermanager wie {{Monospace|[[EMM386.EXE|EMM386]]}}, die unautorisierte Zugriffe auf das A20-Gate abfangen und softwaretechnisch entsprechend verarbeiten können, schafften hier betriebssystemseitig mehr Sicherheit in der Verwendung der HMA. Rechner, bei denen die A20-Leitung nicht maskierbar ist, sind zwar von solchen Problemen nicht betroffen, allerdings gibt es auch einzelne DOS-Programme, die mit solchen Rechnern nicht kompatibel sind.

Ein weiterer Punkt ist jedoch die Adressierung des Codes innerhalb der HMA selbst. Bei einer Relokation in die [[Upper Memory Area]] (UMA), wie sie für normale Treiber möglich ist, wird normalerweise die Segmentadresse an das Zielsegment angepasst – im Falle der HMA steht die Segmentadresse jedoch fest auf FFFEhex oder FFFFhex, so dass, wenn mehrere Software-Komponenten gleichzeitig in die HMA geladen werden sollen, sich stattdessen die Offset-Adressen ändern müssen, da zum Zeitpunkt der Kompilierung noch nicht bekannt sein kann, an welcher Stelle innerhalb des HMA-Segments gerade noch Platz für den hochzuladenden Code sein wird. Diese Intra-Segment-Offset-Relokation erfordert spezielle Ladetechniken, bei denen alle Offsetbezüge innerhalb des Codes beim Laden entsprechend angepasst werden müssen. Die Verwendung der HMA in eigenen Programmen erforderte somit die Anwendung verschiedener Programmiertricks, die nur wenige DOS-Programmierer der damaligen Zeit auch beherrschten.<ref>{{cite web |title=Treiber dynamisch nachladen (Intra-Segment-Offset-Relokation zum Laden von TSRs in die HMA) |author=Matthias Paul |date=2002-02-02 |work=de.comp.os.msdos |url=https://groups.google.com/d/msg/de.comp.os.msdos/tdvpBoMVN6A/a_zqDxGk22IJ |access-date=2017-07-02}}</ref>

== Begriffsverwirrung ==
In den deutschsprachigen MS-DOS-Versionen, die die HMA unterstützen, wird diese als „oberer Speicherbereich“ bezeichnet. Als die Unterstützung für [[Upper Memory Block]]s (UMBs) hinzukam, verwendete man dann für diese den Namen „hoher Speicherbereich“. Die Benennung war also im Deutschen genau umgekehrt gehandhabt wie im Englischen, was zusammen mit der insgesamt schweren Verständlichkeit der MS-DOS-Speicherverwaltung zu viel Verwirrung bei den Anwendern führte. Erst unter [[Microsoft Windows 95|Windows 95]] wurden die deutschen Begriffe vertauscht, so dass sie nun der direkten Übersetzung aus dem Englischen entsprechen.

== Einzelnachweise ==
<references />

[[Kategorie:Speicherverwaltung]]

High Memory Area - Versionsgeschichte

~2025-42954-99: /* Entstehungsgeschichte */ typo