DOS memory management

The term High Memory Area (HMA ) referred to at an x86 - compatible processor, the first 65520 bytes above the 1 MiB boundary. The German translation of high memory area has now fallen into disuse.

Genesis

Under DOS, an x86 -compatible processor in real mode is operated, causing it to behave terms of software such as the CPU 8086er/8088er the first IBM PCs. This is only the first MiB of RAM addressable (addresses: 00000hex ... FFFFFhex ). By the usual in real mode addressing in the segment offset format but can also generate physical memory address locations that lie beyond 1 MiB, namely to 10FFEFhex. For binary representation of these addresses are 21 address lines needed. Since 8086, however, only 20 address lines (A0 to A19 ) that the output from the processor address are truncated accordingly. The addresses of 100000hex 10FFEFhex to be so issued as 00000hex to 0FFEFhex.

With the release of the 80286 processors changed this behavior because this had 24 address lines and so was able to pass the correct addresses to the memory. This led to problems because the BIOS as well as some DOS programs used this "wrap around " and relied on that the addresses would be truncated at 1 MiB. In order to continue to be as compatible with the 8086, an additional circuit was on the motherboards added that the 21st address line (A20, is because counting from 0 ) is disabled. This circuit is referred to as " gate A20 ." When the computer starts, the 21st address line is disabled, the " A20 gate " is closed. About specific hardware commands can be opened and activate the 21st address line the " A20 gate ". Thus, the addresses are no longer truncated to 20 bits, and you get access to the memory above 1 MiB.

Although the opening of the A20 " Gates" was intended only for the protected mode, this worked well in real mode, only the first 65520 bytes (ie almost 64 KiB) are addressable in real mode, however, beyond the 1 MiB boundary. Some device drivers took advantage of this trick, use and placed in this memory area.

HIMEM.SYS / HIDOS.SYS

Since DOS only managed the first mebibyte of main memory, problems occurred when more than one program or driver HMA wanted to use. To solve this problem, were (eg HIMEM.SYS ), which controlled access to the extended memory, added functions which govern the allocation and release of the HMA in the memory manager.

Use of the HMA

From DR DOS version 5.0 (1990) and MS -DOS version 5.0 (1991 ) DOS was able to shift its own kernel in the HMA if HIDOS.SYS or HIMEM.SYS was loaded. This was = ON or DOS = HIGH achieved by the Hidos option in the configuration file CONFIG.SYS. This was less " conventional memory ", ie memory below the 640 KiB boundary, occupied by DOS core that was beneficial in the chronic shortage of memory under DOS.

In DR DOS not only a part of the system core could be even moved into the HMA, but also the resident portion of the command line interpreter COMMAND.COM (with option / MH), portions of the buffer management ( HIBUFFERS ) and from DR DOS 6.0 a number of specially designed for this purpose drivers like Keyb, NLSFUNC and SHARE (each with option / MH), which further conventional memory for applications and regular driver was released.

From DR- DOS 7:02 allowed parameter SIZE = xxxx is the configuration directive SHELL HIGH = fine adjustment of the Präallokation for the resident portion of the command line processor, which could be a fragmentation of the HMA prevented especially in the use of alternative command line processors, such as 4DOS (about SHELL HIGH SIZE = 20 c: \ 4dos.com ... in CONFIG.SYS ), so that a total of more contiguous free space for HMA -enabled driver is available.

Although the widest possible use of the HMA was desirable by drivers, made ​​a total of only relatively few drivers use of it and if so, then usually only exclusive, without then also simultaneously parts of the operating system or other drivers could be uploaded into the HMA.

Due to the fact that the address line A20 was masked over the A20 gate at any time from other running processes, whereby the HMA was temporarily not available, only parts of the program in the HMA could be displaced, the short- functions (so called " stubs" ) were skipped in conventional memory, was in place to ensure that the A20 line was temporarily re-enabled before any code or data in the HMA have been addressed, eg no interrupt routines. Also the calling external subroutines ( with not always fully known side effects caused by TSRs ) from the HMA out or interrupted by interrupts was not critical and required special precautionary measures in the implementation, as it otherwise the A20 gate state " seemingly random " could change. Since this requires only rudimentary APIs have been made ​​available on the part of the operating system and a safe implementation to observe some not immediately obvious race conditions were an upload option for some drivers, depending on the task was technically not in principle accessible to realize at least expensive for others. Only 386 memory manager such as EMM386, which could intercept unauthorized access to the A20 gate and processed by software appropriately managed here operating system side more security in the use of the HMA. Even on machines where the A20 line is not masked, it was immune to such problems.

However, another point was the addressing of the code within the HMA itself With a relocation in the " Upper Memory Area " ( UMA), as it was possible for ordinary drivers, normally the segment address has been adapted to the target segment, stood in the case of HMA the segment address but firmly on FFFEhex or FFFFhex, so that when multiple software components should be simultaneously loaded into the HMA, instead had the offset addresses change, because at compile time was not known at what point within the HMA segment just would be space for the code to be uploaded yet. However, these intra -segment offset relocation required special charging techniques in which all offset compensation were adjusted accordingly within the code loading, and the use of various programming tricks that dominated only a few programmers.

Confusion

In the German MS -DOS versions which supported the HMA, as these "upper memory area" was designated. As support for Upper Memory Blocks was added, would then be used for this called " high memory area ". The designation was thus handled just reversed in German as in English, which led, together with the total heavy intelligibility of the MS -DOS memory management too much confusion among users. Only under Windows 95, the German terms were reversed, so that they now correspond to direct the English.

• Memory management