High memory area
History of origin
Under DOS , a is x86 -compatible processor in real mode operated, whereby the software of view as the 8086 / 8088er CPU of the first IBM PCs behaves. This means that only the first MiB of the RAM can be addressed (addresses: 00000 hex … FFFFF hex ). However, the usual addressing in the segment offset format in real mode also allows the generation of physical memory addresses that are beyond 1 MiB, namely up to 10FFEF hex . 21 address lines are required for the binary representation of these addresses. Since the 8086 only has 20 address lines ( A0 to A19 ), the addresses output by the processor are cut off accordingly. The addresses from 100000 hex to 10FFEF hex are output as 00000 hex to 0FFEF hex .
With the appearance of the 80286 processors, this behavior changed, as it had 24 address lines and was able to pass the correct addresses on to the memory. This led to problems, because the BIOS and some DOS programs used this "wrap around" and relied on the addresses being cut off at 1 MiB. In order to be as compatible as possible with the 8086, an additional circuit has been added to the main circuit board , which deactivates the 21st address line ( A20 , since counting from 0). This circuit is known as the " A20 gate ". When the computer starts, the 21st address line is deactivated and the "A20 gate" is closed. The “A20 gate” can be opened and the 21st address line activated via certain hardware commands. This means that the addresses are no longer truncated to 20 bits and access to the memory is over 1 MiB.
Although opening the "A20 gate" was only intended for protected mode , this also worked in real mode, although in real mode only the first 65520 bytes (almost 64 KiB) beyond the 1 MiB limit can be addressed. Some device drivers made use of this trick and placed themselves in this memory area.
HIMEM.SYS / HIDOS.SYS
Since DOS only managed the first mebibyte of main memory, problems arose as soon as more than one program or driver tried to use the HMA. To solve this problem, functions were added to the memory manager (e.g.
HIMEM.SYS), which regulated access to the extended memory, which regulated the reservation and release of the HMA.
Use of the HMA
From DR DOS version 5.0 (1990) and MS-DOS version 5.0 (1991), DOS was able to relocate its own system kernel to the HMA when HIDOS.SYS or HIMEM.SYS was loaded. This was achieved with the option
DOS=HIGHin the CONFIG.SYS configuration file . This means that less “ conventional memory ”, ie memory below the 640 KiB limit, was used by the DOS kernel, which was advantageous in view of the chronic memory shortage under DOS.
With DR DOS, not only could part of the system kernel itself be moved into the HMA, but also the resident part of the command line interpreter COMMAND.COM (with the / MH option), parts of the buffer management (
HIBUFFERS) and, from DR DOS 6.0, a whole range of special functions designed drivers such as KEYB, NLSFUNC and SHARE (each with the / MH option), which frees up more conventional memory for applications and normal drivers.
As of DR-DOS 7.02, the parameter of
SHELLHIGH=directive allowed a fine adjustment of the preallocation for the resident part of the command line processor, whereby a fragmentation of the HMA could be prevented especially when using alternative command line processors like 4DOS (
SHELLHIGH SIZE=20 c:\4dos.com ...e.g. with in CONFIG.SYS), so that overall Even more contiguous free storage space for HMA-compatible drivers became available.
Although the widest possible use of the HMA by drivers was desirable, overall only a comparatively few drivers made use of it and if so, then usually only exclusively, without parts of the operating system or other drivers being uploaded to the HMA at the same time.
Due to the fact that the address line A20 could be masked by other running processes at any time via the A20 gate, which meant that the HMA could temporarily no longer be reached, only program parts could be relocated to the HMA that were via short functions (so-called stubs ) in the conventional Memories were accessed in which it was ensured that the A20 line was temporarily reactivated before code or data was addressed in the HMA, e.g. B. no interrupt routines. The call of external subroutines (with not always fully known side effects from TSRs ) from the HMA or the interruption by interrupts was not uncritical and required special precautionary measures in the implementation, since otherwise the state of the A20 gate "apparently randomly" could change. Since only rudimentary APIs were made available by the operating system for this and a number of race conditions that were not immediately obvious had to be taken into account for a secure implementation, an upload option for some drivers was technically not achievable depending on the task, for others it was at least difficult to implement. Only 386 memory managers such as EMM386, which could intercept unauthorized access to the A20 gate and process it appropriately using the software, created more security in the use of the HMA on the operating system side. Even on computers where the A20 line cannot be masked, one was immune to such problems.
Another point, however, was the addressing of the code within the HMA itself. When relocating to the Upper Memory Area (UMA), as was possible for normal drivers, the segment address was usually adapted to the target segment; in the case of the HMA, the segment address was given but fixed to FFFE hex or FFFF hex , so that if several software components were to be loaded into the HMA at the same time, the offset addresses had to be changed instead, since at the time of compilation it was not yet clear at which point within the HMA Segment, there would just be enough space for the code to be uploaded. However, this intra-segment offset relocation required special loading techniques in which all offset references within the code were adjusted accordingly during loading, and the use of various programming tricks that only a few programmers could master.
Confusion of terms
In the German-language MS-DOS versions that supported the HMA, this was referred to as the "upper memory area". When support for upper memory blocks was added, it was called "high memory block". The naming was handled the other way around in German than in English, which, together with the overall difficult understanding of the MS-DOS memory management, led to a lot of confusion among users. The German terms were only swapped under Windows 95 so that they now corresponded directly to the English.
- driver dynamically (intra-segment offset relocation for loading TSRs into the HMA) . In: de.comp.os.msdos . February 2, 2002.