Editing High memory area (section)

{{Short description|RAM area of an IBM AT or compatible computer}}
{{Distinguish|High memory}}
{{Use dmy dates|date=May 2019|cs1-dates=y}}
{{Use list-defined references|date=December 2021}}
[[File:IBM PC Memory areas.svg|thumb|The high memory area is highlighted.]]
In [[DOS memory management]], the '''high memory area''' ('''HMA''') is the [[random-access memory|RAM]] area consisting of the first 65520 [[byte]]s above the one megabyte in an [[IBM]] [[IBM AT|AT]] or compatible computer.

In [[real mode]], the [[x86 memory segmentation|segmentation architecture]] of the [[Intel]] [[Intel 8086|8086]] and subsequent processors identifies memory locations with a 16-bit segment and a 16-bit offset, which is resolved into a physical address via (segment) × 16 + (offset). Although intended to address only 1&nbsp;[[Megabyte]] (MB) (2<sup>20</sup> bytes) of memory, segment:offset addresses at <code>FFFF:0010</code> and beyond reference memory beyond 1&nbsp;MB (<code>FFFF0 + 0010 = 100000</code>). So, on an [[Intel 80286|80286]] and subsequent processors, this mode can actually address the first 65520&nbsp;bytes of extended memory as part of the 64&nbsp;KB range starting 16&nbsp;bytes before the 1&nbsp;MB mark—<code>FFFF:0000 (0xFFFF0)</code> to <code>FFFF:FFFF (0x10FFEF)</code>. The Intel [[Intel 8086|8086]] and [[Intel 8088|8088]] processors, with only 1&nbsp;MB of memory and only 20&nbsp;[[address line]]s, wrapped around at the 20th bit, so that address <code>FFFF:0010</code> was equivalent to <code>0000:0000</code>.<ref name="Paul_2002_HMA"/>

To allow running existing DOS programs which relied on this feature to access [[low memory]] on their newer IBM [[PC AT]] computers, IBM added special [[circuitry]] on the [[motherboard]] to simulate the wrapping around. This circuit was a simple [[logic gate]] which could disconnect the microprocessor's 21st addressing line, [[A20 line|A20]], from the rest of the motherboard. This gate could be controlled, initially through the [[keyboard controller (computing)|keyboard controller]], to allow running programs which wanted to access the entire RAM.<ref name="Paul_2002_HMA"/>

So-called [[A20 handler]]s could control the addressing mode dynamically,<ref name="Paul_2002_HMA"/> thereby allowing programs to load themselves into the 1024–1088&nbsp;KB region and run in real mode.<ref name="Paul_2002_HMA"/>

Code suitable to be executed in the HMA must either be coded to be [[position-independent code|position-independent]] (using only relative references),<ref name="Ingenoso_1998"/><ref name="Paul_2002_HMA"/> be compiled to work at the specific addresses in the HMA (typically allowing only one or at most two pieces of code to share the HMA<!-- with one loaded at the top and the other at the bottom of the HMA -->), or it must be designed to be [[paragraph boundary relocatable|paragraph boundary]] or even [[offset relocatable]] (with all addresses being fixed up during load).<ref name="Ingenoso_1998"/><ref name="Paul_2002_HMA"/>

Before code (or data) in the HMA can be addressed by the CPU, the corresponding driver must ensure that the HMA is mapped in. This requires that any such requests are tunneled through a [[DOS memory stub|stub]] remaining in memory outside the HMA, which would invoke the A20 handler in order to (temporarily) enable the [[A20 gate]].<ref name="Ingenoso_1998"/><ref name="Paul_2002_HMA"/> If the driver does not exhibit any public data structures and only uses interrupts or calls already controlled by the underlying operating system, it might be possible to register the driver with the system in a way so that the system will take care of A20 itself thereby eliminating the need for a separate stub.<ref name="Paul_2002_HMA"/><ref group="nb" name="NB_Backdoor"/>

The first user of the HMA among [[Microsoft]] products was [[Windows/286]]&nbsp;2.1 in 1988, which introduced the [[HIMEM.SYS]] device driver. Starting in 1990 with [[Digital Research]]'s [[DR&nbsp;DOS 5.0]]<ref name="Dryfoos_1991_DOS5"/> (via <kbd>HIDOS.SYS /[[BDOS (DOS)|BDOS]]=FFFF</kbd><ref name="Novell_1994_DR6"/> and [[CONFIG.SYS]] <kbd>[[HIDOS (CONFIG.SYS directive)|HIDOS]]=ON</kbd>) and since 1991 with [[MS-DOS 5.0]]<ref name="Dryfoos_1991_DOS5"/> (via <kbd>[[DOS (CONFIG.SYS directive)|DOS]]=HIGH</kbd>), parts of the operating system's [[DOS BIOS|BIOS]] and kernel could be loaded into the HMA as well,<ref name="Dryfoos_1991_DOS5"/><ref name="Schulman_1994_Undocumented-DOS"/> freeing up to 46&nbsp;KB of [[conventional memory]].<ref name="Paul_2002_HMA"/> Other components, such as device drivers and [[terminate-and-stay-resident program]]s (TSRs), could at least be loaded into the [[upper memory area]] (UMA), but not into the HMA. Under DOS 5.0 and higher, with <kbd>DOS=HIGH</kbd>, the system additionally attempted to move the disk buffers into the HMA.<ref name="Schulman_1994_Undocumented-DOS"/> Under [[DR&nbsp;DOS 6.0]] (1991) and higher, the disk buffers (via <kbd>[[HIBUFFERS (CONFIG.SYS directive)|HIBUFFERS]]</kbd>, and later also <kbd>[[BUFFERSHIGH (CONFIG.SYS directive)|BUFFERSHIGH]]</kbd>), parts of the command processor [[COMMAND.COM]] as well as several special [[self-relocating]] drivers like [[KEYB (DOS command)|KEYB]], [[NLSFUNC (DOS command)|NLSFUNC]] and [[SHARE (DOS command)|SHARE]] could load into the HMA as well (using their <kbd>/MH</kbd><!-- KEYB/NLSFUNF/SHARE would attempt to load high by default, but the switch could be used to control the behaviour --> option), thereby freeing up even more conventional memory and upper memory for conventional DOS software to work with.<ref name="Paul_2002_HMA"/> [[TASKMAX]] seems to have relocated parts of itself into the HMA as well.<ref name="RBIL_2000_HMA"/><ref name="Paul_2002_MSDOS7"/> [[Novell]]'s [[Novell NLCACHE|NLCACHE]] from [[NetWare Lite]]<!-- at least in NetWare Lite 1.1 (1992), not sure about NWL 1.0 from 1991 --> and early<!-- beta versions from 1993 --> versions of [[Novell NWCACHE|NWCACHE]] from [[Personal NetWare]]<!-- pre-1.0 --> and [[Novell DOS 7]] could utilize the HMA as well.<ref name="Paul_1997_NWDOSTIP"/><ref name="Paul_2001_NWDOSTIP"/><ref name="Paul_2002_MSDOS7"/> Under MS-DOS/PC&nbsp;DOS, a ca. 2&nbsp;KB shared portion of COMMAND.COM can be relocated into the HMA,<ref name="Chappell_1994_Internals"/> as well as [[DISPLAY.SYS]] bitmaps for prepared [[codepage]]s.<ref name="Chappell_1994_Internals"/><ref name="Paul_2002_DISPLAY"/> Under [[MS-DOS 6.2]]<!-- not 6.0 --> (1993) and higher, a ca. 5&nbsp;KB portion of [[DBLSPACE.BIN]]/[[DRVSPACE.BIN]] can coexist with DOS in the HMA (unless [[DBLSPACE]]/[[DRVSPACE]] <kbd>/NOHMA</kbd> is invoked).<ref name="Schulman_1994_Undocumented-DOS"/><ref name="Cooper_2002_MS-DOS"/> Under [[PC&nbsp;DOS 7.0]] (1995) and [[PC DOS 2000|2000]], [[DOSKEY]] loads into the HMA (if available),<ref name="Brooks_2014_HMA"/> and SHARE can be loaded into the HMA as well (unless its <kbd>/NOHMA</kbd> option is given).<ref name="Brooks_2014_HMA"/> Under [[MS-DOS 7.0]] (1995) to [[MS-DOS 8.0|8.0]] (2000), parts of the HMA are also used as a scratchpad to hold a growing data structure recording various properties of the loaded real-mode drivers.<ref name="Paul_2002_MSDOS7"/><ref name="Sweger_2002"/><ref name="Paul_2002_HMA7"/>