 | This article has multiple issues. Please helpimprove it or discuss these issues on thetalk page.(Learn how and when to remove these messages) (Learn how and when to remove this message)
|
InDOS memory management, thehigh memory area (HMA) is theRAM area consisting of the first 65520bytes above the onemegabyte in anIBMAT or compatible computer.
Inreal mode, thesegmentation architecture of theIntel8086 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) (220 bytes) of memory, segment:offset addresses atFFFF:0010 and beyond reference memory beyond 1 MB (FFFF0 + 0010 = 100000). So, on an80286 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) toFFFF:FFFF (0x10FFEF). The Intel8086 and8088 processors, with only 1 MB of memory and only 20 address lines, wrapped around at the 20th bit, so that addressFFFF:0010 was equivalent to0000:0000.[1]
To allow running existing DOS programs which relied on this feature to accesslow memory on their newer IBMPC AT computers, IBM added specialcircuitry on themotherboard to simulate the wrapping around. This circuit was a simplelogic gate which could disconnect the microprocessor's 21st addressing line,A20, from the rest of the motherboard. This gate could be controlled, initially through thekeyboard controller, to allow running programs which wanted to access the entire RAM.[1]
So-calledA20 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 beposition-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 beparagraph boundary or evenoffset relocatable (with all addresses being fixed up during load).[2][1]
Before code (or data) in the HMA can be addressed by theCPU, the corresponding driver must ensure that the HMA is mapped in. This requires that any such requests are tunneled through astub remaining in memory outside the HMA, which would invoke the A20 handler in order to (temporarily) enable theA20 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 amongMicrosoft products wasWindows/286 2.1 in 1988, which introduced theHIMEM.SYS device driver. Starting in 1990 withDigital Research'sDR DOS 5.0[3] (viaHIDOS.SYS /BDOS=FFFF[4] andCONFIG.SYSHIDOS=ON) and since 1991 withMS-DOS 5.0[3] (viaDOS=HIGH), parts of the operating system'sBIOS and kernel could be loaded into the HMA as well,[3][5] freeing up to 46 KB ofconventional memory.[1] Other components, such as device drivers andterminate-and-stay-resident programs (TSRs), could at least be loaded into theupper memory area (UMA), but not into the HMA. Under DOS 5.0 and higher, withDOS=HIGH, the system additionally attempted to move the disk buffers into the HMA.[5] UnderDR DOS 6.0 (1991) and higher, the disk buffers (viaHIBUFFERS, and later alsoBUFFERSHIGH), parts of the command processorCOMMAND.COM as well as several specialself-relocating drivers likeKEYB,NLSFUNC andSHARE 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'sNLCACHE fromNetWare Lite and early versions ofNWCACHE fromPersonal NetWare andNovell 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 asDISPLAY.SYS bitmaps for preparedcodepages.[10][11] UnderMS-DOS 6.2 (1993) and higher, a ca. 5 KB portion ofDBLSPACE.BIN/DRVSPACE.BIN can coexist with DOS in the HMA (unlessDBLSPACE/DRVSPACE/NOHMA is invoked).[5][12] UnderPC DOS 7.0 (1995) and2000,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] UnderMS-DOS 7.0 (1995) to8.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]
[…] One of the most important stimulanta for adding features was competitive pressure fromDRDOS 5.0, which we first learnt of in the spring of 1990. The DRDOS feature set led us to addUMB support, task swapping, and Undelete. […] Considerable amounts of the team's management attention was diverted to new features such as file transfer software, undelete and network installation […] Eventually this situation reached a crisis point at the end of July 1990, and, led byBradS, the team's management spent an arduous series of meetings nailing down a schedule and process for closing the project down […](1+32 pages)
[…]MS-DOS 7.0+ adds INT 21h/AX=4A03h and INT 21h/AX=4A04h.RBIL61 INT 21h/AH=52h has some info on the MS-DOS 7.0+ HMA MCB chain […] HMA relocation for TSRs makes much sense forDR-DOS: Although you can load large parts of theBIOS andBDOS, the resident part of the shell, theBUFFERS, and DR-DOS TSRs likeSHARE,KEYB, andNLSFUNC (and in some issues parts of TASKMGR andNWCACHE) into the HMA, there is usually still free space available, typically around 10 Kb (up to ca. 20 Kb when you use a 3rd party shell). It also makes sense forMS-DOS 5.0 -6.22 andPC DOS up to2000, which typically leave 4 - 7 Kb of the HMA memory unused (SHARE, KEYB, and NLSFUNC cannot load into the HMA, butDBLSPACE andHIMEM can to some extent). Available HMA space can be rather tight withMS-DOS 7.0+, since this issue introduced a new and for the most part undocumented RMD data structure usually located in the HMA. The kernel collects and records configuration and Real Mode Driver data during boot (type of driver, interrupts hooked by driver,CONFIG.SYS line of invocation, etc.) and stores this information in an […] complicated […] and […] growing data structure. Presumably this info is meant to be used by the Windows core to get a better picture of the loaded Real Mode drivers instead of treating DOS as a monolithic block, or even […] attempt to unhook or unload some of them, however, it is only used to a very limited extent (for example you can see some of the info reflected in the log files created on Windows 9x startup, and some parts of the Windows configuration manager also make use of it), leaving room for speculation much beyond the technical side - in particular because nothing of the interesting stuff is documented… […]
NWDOSTIP.TXT is a comprehensive work onNovell DOS 7 andOpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet largerMPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the file.)[4][…] some issues of DISPLAY.SYS (ofPC DOS 7/2000, for example) store the currently unused fonts inXMS memory. Some earlier issues of MS-DOS/PC DOSDISPLAY.SYS seem to have had a facility to store them in the HMA […]
[…]DOSKEY.COM […] Move code to HMA if available. […]SHARE.EXE […] Move code to HMA if available and added /NOHMA option force loading low. […]
[…] ANSIPLUS's code cannot be loaded to the HMA underMS-DOS 7 (Windows 9x only) because there apparently is not enough unused HMA memory available. […]
[…]86-DOS, and hencePC DOS/MS-DOS, used a clever trick. The byte at offset 5 of thePSP 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 the8086 CPU) and point to address 0:C0h, which contains interrupt vector 30h. […] theCALL 5 interface works even in DOS emulation under Windows NT and OS/2, and those systems most certainly cannot run with theA20 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 withDOS=HIGH. In that case, DOS makes sure that linear address 1000C0h contains the appropriate far call. […]
[…] in case of suchmangled 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 aA20 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 supportingIBM'sInterrupt 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. […]