High memory area

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "High memory area" – news · newspapers · books · scholar · JSTOR (October 2025) (Learn how and when to remove this message) This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (October 2025) (Learn how and when to remove this message) (Learn how and when to remove this message)

In DOS memory management, the high memory area (HMA) is the RAM area consisting of the first 65520 bytes above the one megabyte in an IBM AT or compatible computer.

In real mode, the segmentation architecture of the Intel 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 Megabyte (MB) (2²⁰ bytes) of memory, segment:offset addresses at FFFF:0010 and beyond reference memory beyond 1 MB (FFFF0 + 0010 = 100000). So, on an 80286 and subsequent processors, this mode can actually address the first 65520 bytes of extended memory as part of the 64 KB range starting 16 bytes before the 1 MB mark—FFFF:0000 (0xFFFF0) to FFFF:FFFF (0x10FFEF). The Intel 8086 and 8088 processors, with only 1 MB of memory and only 20 address lines, wrapped around at the 20th bit, so that address FFFF:0010 was equivalent to 0000:0000.^[1]

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, from the rest of the motherboard. This gate could be controlled, initially through the keyboard controller, to allow running programs which wanted to access the entire RAM.^[1]

So-called A20 handlers could control the addressing mode dynamically,^[1] thereby allowing programs to load themselves into the 1024–1088 KB region and run in real mode.^[1]

Code suitable to be executed in the HMA must either be coded to be position-independent (using only relative references),^[2][1] 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), or it must be designed to be paragraph boundary or even offset relocatable (with all addresses being fixed up during load).^[2][1]

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 stub remaining in memory outside the HMA, which would invoke the A20 handler in order to (temporarily) enable the A20 gate.^[2][1] 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.^{[1][nb 1]}

The first user of the HMA among Microsoft products was Windows/286 2.1 in 1988, which introduced the HIMEM.SYS device driver. Starting in 1990 with Digital Research's DR DOS 5.0^[3] (via HIDOS.SYS /BDOS=FFFF^[4] and CONFIG.SYS HIDOS=ON) and since 1991 with MS-DOS 5.0^[3] (via DOS=HIGH), parts of the operating system's BIOS and kernel could be loaded into the HMA as well,^[3][5] freeing up to 46 KB of conventional memory.^[1] Other components, such as device drivers and terminate-and-stay-resident programs (TSRs), could at least be loaded into the upper memory area (UMA), but not into the HMA. Under DOS 5.0 and higher, with DOS=HIGH, the system additionally attempted to move the disk buffers into the HMA.^[5] Under DR DOS 6.0 (1991) and higher, the disk buffers (via HIBUFFERS, and later also BUFFERSHIGH), parts of the command processor COMMAND.COM as well as several special self-relocating drivers like KEYB, NLSFUNC and SHARE could load into the HMA as well (using their /MH option), thereby freeing up even more conventional memory and upper memory for conventional DOS software to work with.^[1] TASKMAX seems to have relocated parts of itself into the HMA as well.^[6][7] Novell's NLCACHE from NetWare Lite and early versions of NWCACHE from Personal NetWare and Novell DOS 7 could utilize the HMA as well.^[8][9][7] Under MS-DOS/PC DOS, a ca. 2 KB shared portion of COMMAND.COM can be relocated into the HMA,^[10] as well as DISPLAY.SYS bitmaps for prepared codepages.^[10][11] Under MS-DOS 6.2 (1993) and higher, a ca. 5 KB portion of DBLSPACE.BIN/DRVSPACE.BIN can coexist with DOS in the HMA (unless DBLSPACE/DRVSPACE /NOHMA is invoked).^[5][12] Under PC DOS 7.0 (1995) and 2000, DOSKEY loads into the HMA (if available),^[13] and SHARE can be loaded into the HMA as well (unless its /NOHMA option is given).^[13] Under MS-DOS 7.0 (1995) to 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.^[7][14][15]

• Expanded memory (EMS)
• Extended memory (XMS)
• HMAREA (CONFIG.SYS directive) to specify the HMA segment (PTS-DOS only), similar to the DR DOS HIDOS.SYS /BDOS=xxxx parameter
• Incomplete address decoding
• Intra-segment offset relocation
• Rebasing
• SHELLHIGH (CONFIG.SYS directive) SIZE=xxxx parameter to override default HMA pre-allocation (DR-DOS 7.02 and higher only)^[16]
• Unreal mode

• Necasek, Michal (2011-09-13). "Who needs the address wraparound, anyway?". OS/2 Museum. Archived from the original on 2020-02-19. Retrieved 2020-02-19. […] 86-DOS, and hence PC DOS/MS-DOS, used a clever trick. The byte at offset 5 of the PSP contained a far call opcode (9Ah); the word at offset 6 of the PSP contained the appropriate value to indicate program segment size, and also the offset part of the far call. The word at offset 8, which served as the segment part of the far call, was crafted such that when combined with the offset, it would wrap around (a well understood feature of the 8086 CPU) and point to address 0:C0h, which contains interrupt vector 30h. […] the CALL 5 interface works even in DOS emulation under Windows NT and OS/2, and those systems most certainly cannot run with the A20 line disabled. How does that work then? […] Rather than chopping off address bits, the system mirrors the five bytes at 0:C0h at 1000C0h. The same technique had been in fact used in DOS 5 and above running with DOS=HIGH. In that case, DOS makes sure that linear address 1000C0h contains the appropriate far call. […]
• Kozierok, Charles M. (2001-04-17) [1997]. "High Memory Area (HMA)". The PC Guide. 2.2.0. Archived from the original on 2006-10-16. Retrieved 2006-10-15.
• Paul, Matthias R. (2002-04-11). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev. Archived from the original on 2020-02-21. Retrieved 2020-02-21. […] in case of such mangled pointers […] many years ago Axel and I were thinking about a way how to use *one* entry point into a driver for multiple interrupt vectors (as this would save us a lot of space for the multiple entry points and the more or less identical startup/exit framing code in all of them), and then switch to the different interrupt handlers internally. For example: 1234h:0000h […] 1233h:0010h […] 1232h:0020h […] 1231h:0030h […] 1230h:0040h […] all point to exactly the same entry point. If you hook INT 21h onto 1234h:0000h and INT 2Fh onto 1233h:0010h, and so on, they would all go through the same "loophole", but you would still be able to distinguish between them and branch into the different handlers internally. Think of a "compressed" entry point into a A20 stub for HMA loading. This works as long as no program starts doing segment:offset magics. […] Contrast this with the opposite approach to have multiple entry points (maybe even supporting IBM's Interrupt Sharing Protocol), which consumes much more memory if you hook many interrupts. […] We came to the result that this would most probably not be save in practise because you never know if other drivers normalize or denormalize pointers, for what reasons ever. […]