Misplaced Pages

#640359

29-542: EMM386.EXE can map memory into unused blocks in the upper memory area (UMA), allowing device drivers and terminate-and-stay-resident programs to be "loaded high", preserving conventional memory . The technique probably first appeared with the development of CEMM , included with Compaq's OEM MS-DOS for the Compaq Deskpro 386 in 1986. Microsoft's version first appeared, built-in, with Windows/386 2.0 in 1987 and as standalone EMM386.SYS with MS-DOS 4.0 in 1988;

58-592: A few memory managers implemented the GEMMIS API, some of the ones that include it are: EMM386.EXE, Quarterdeck QEMM , Qualitas 386MAX , Helix Netroom and DOSBox builtin DOS . Notably missing are FreeDOS's memory managers. None of the FreeDOS memory managers (HIMEMX.EXE, JEMM386.EXE, JEMMEX.EXE) implement the GEMMIS API and Windows fails to start when running in conjunction with JEMMxxx since Windows fails to take over

87-539: A multitasking manager) were still thus constrained. With the release of Windows 95 , it became less relevant still, as this version of Windows provides much of the functionality of the DOS device drivers to DOS applications running under Windows, such as CD, network and sound support; the memory map of Windows 95 DOS boxes was automatically optimised. However, not all DOS programs could execute in this environment. Specifically, programs that tried to directly switch from real mode to protected mode would not work as this

116-487: A program called MEMMAKER which was used to automatically optimize conventional memory by moving terminate-and-stay-resident (TSR) programs to the upper memory. For a period in the early 1990s, manual optimization of the DOS memory map became a highly prized skill, allowing for the largest applications to run on even the most complex PC configurations. The technique was to first create as many UMBs as possible, including remapping allocated but unused blocks of memory, such as

145-523: Is limited in functionality, it lacks virtual memory, it skips the [386Enh] section in SYSTEM.INI and any device drivers in [386Enh] are not loaded. This DOS software-related article is a stub . You can help Misplaced Pages by expanding it . Upper memory area In DOS memory management , the upper memory area ( UMA ) is the memory between the addresses of 640  KB and 1024 KB ( 0x A0000–0xFFFFF) in an IBM PC or compatible. IBM reserved

174-420: The 640 KB barrier was removed at the cost of software compatibility. This usage of the upper memory area is different from using upper memory blocks, which was used to free conventional memory by moving device drivers and TSRs into the upper 384 KB of the 1  MB address space, but left the amount of addressable memory (640 KB) intact. High memory area In DOS memory management ,

203-762: 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

232-463: 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. So-called A20 handlers could control the addressing mode dynamically, thereby allowing programs to load themselves into

261-569: The 1024–1088 KB region and run in real mode. Code suitable to be executed in the HMA must either be coded to be position-independent (using only relative references), 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). Before code (or data) in

290-452: The HMA as well. Novell 's NLCACHE from NetWare Lite and early versions of NWCACHE from Personal NetWare and Novell DOS 7 could utilize the HMA as well. Under MS-DOS/PC DOS, a ca. 2 KB shared portion of COMMAND.COM can be relocated into the HMA, as well as DISPLAY.SYS bitmaps for prepared codepages . Under MS-DOS 6.2 (1993) and higher, a ca. 5 KB portion of DBLSPACE.BIN / DRVSPACE.BIN can coexist with DOS in

319-550: 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 . If the driver does not exhibit any public data structures and only uses interrupts or calls already controlled by

SECTION 10

#1732780118641

348-487: The HMA. 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. TASKMAX seems to have relocated parts of itself into

377-589: The combination of an older DOS plus QEMM was that the DR ;DOS kernel itself and almost all of its data structures could be loaded into high memory. This left virtually all the base memory free, allowing configurations with up to 620 KB out of 640 KB free. Configuration was not automatic - free UMBs had to be identified by hand, manually included in the line that loaded EMM386 from CONFIG.SYS , and then drivers and so on had to be manually loaded into UMBs from CONFIG.SYS and AUTOEXEC.BAT . This configuration

406-462: The empty areas with RAM. These areas were referred to as upper memory blocks ( UMBs ). The next stage in the evolution of DOS was for the operating system to use upper memory blocks (UMBs) and the high memory area (HMA). This occurred with the release of DR DOS 5.0 in 1990. DR DOS' built-in memory manager, EMM386.EXE , could perform most of the basic functionality of QEMM and comparable programs. The advantage of DR DOS 5.0 over

435-543: 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 . 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

464-570: The fundamental memory managers into conventional memory, and thereafter everything else into the UMA. Conventional memory glutton programs such as MSCDEX could also be loaded into the UMA in a similar fashion, hence freeing up a large amount of conventional memory. The increasing popularity of Windows 3.0 made the necessity of the upper memory area less relevant, as Windows applications were not directly affected by DOS' base memory limits, but DOS programs running under Windows (with Windows itself acting as

493-432: The memory management role. Windows ME , Windows 98 , Windows 95 , Windows for Workgroups 3.1x , and Windows 3 .xx, all will fail with JEMMxxx displaying: With JEMMxx, it is possible to run Windows 3.x and Windows for Workgroups 3.1x in limited capabilities by forcing Windows to use Standard Mode; i.e. using 80286 Protected Mode, not 80386 Enhanced Mode. Three conditions are required: Note that Windows in standard mode

522-474: The modules of most network stacks had to be loaded in a certain sequence, essentially working progressively up through the layers of the OSI model . A basic yet effective method used to optimize conventional memory was to load HIMEM.SYS as a device, thereafter loading EMM386.EXE as a device with the "RAM AUTO" option which allows access into the UMA by loading device drivers as devicehigh. This method effectively loads

551-543: The monochrome display area on colour machines. Then, DOS' many subcomponents had to be loaded into these UMBs in the correct sequence to use the blocks of memory as efficiently as possible. Some TSR programs required additional memory while loading, which was freed up again once loading was complete. Fortunately, there were few dependencies amongst these modules, so it was possible to load them in almost any sequence. Exceptions were that to successfully cache CD-ROMs, most disk caches had to be loaded after any CD-ROM drivers, and that

580-668: The more flexible EMM386.EXE version appeared in MS-DOS 5.0 in 1991. EMM386 uses the processor's virtual 8086 mode . This forces memory accesses made by DOS applications to go through the processor's MMU (introduced in the 386), and the page table entries used by the MMU are configured by EMM386 to map certain regions in upper memory to areas of extended memory (obtained by EMM386 through the extended memory manager HIMEM.SYS ). This technique enabled both EMS (expanded memory) as well as UMBs - both of which appear to DOS applications to be memory in

609-416: The operating system's BIOS and kernel could be loaded into the HMA as well, freeing up to 46 KB of conventional memory . 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

SECTION 20

#1732780118641

638-584: 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. 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 (via HIDOS.SYS / BDOS =FFFF and CONFIG.SYS HIDOS =ON ) and since 1991 with MS-DOS 5.0 (via DOS =HIGH ), parts of

667-471: The upper area but are in fact mapped to physical memory locations beyond 1MB. It temporarily shuts down during a Windows session in 386 Enhanced mode, with Windows' protected mode kernel taking over its role. Windows uses the GEMMIS API to take over memory management from EMM386.EXE. Global EMM Import Specification (GEMMIS) is supported via a document available to a select number of memory-manager vendors ("Windows/386 Paging Import Specification"). Only

696-423: The upper memory blocks is specified in the eXtended Memory Specification . On many systems including modern ones it is possible to use memory reserved for shadowing expansion card ROM as upper memory. Many chipsets reserve up to 384 KB RAM for this purpose and since this RAM is generally unused it may be used as real mode upper memory with a custom device driver, such as UMBPCI. On IBM XT computers, it

725-647: The uppermost 384 KB of the 8088 CPU 's 1024 KB address space for BIOS ROM , Video BIOS , Option ROMs , video RAM, RAM on peripherals, memory-mapped I/O , and obsoleted ROM BASIC . However, even with video RAM, the ROM BIOS , the Video BIOS , the Option ROMs , and I/O ports for peripherals, much of this 384 KB of address space was unused. As the 640 KB memory restriction became ever more of an obstacle, techniques were found to fill

754-656: Was not a trivial process. As it was largely automated by the installation program of QEMM, this program survived on the market; indeed, it worked well with DR DOS' own HMA and UMB support and went on to be one of the best-selling utilities for the PC. This functionality was copied by Microsoft with the release of MS-DOS 5.0 in June 1991. Eventually, even more DOS data structures were moved out of conventional memory, allowing up to 631 KB out of 640 KB to be left free. Starting from version 6.0 of MS-DOS, Microsoft even included

783-666: Was not allowed in the virtual 8086 mode it was running in. Also, programs that tried making the switch using the Virtual Control Program Interface (VCPI) API (which was introduced to allow DOS programs that needed protected mode to enter it from the virtual 8086 mode set up by a memory manager, as described above) didn't work in Windows ;95. Only the DOS Protected Mode Interface (DPMI) API for switching to protected mode

812-582: Was possible to add more memory to the motherboard and use a custom address decoder PROM to make it appear in the upper memory area. As with the 386-based upper memory described above, the extra RAM could be used to load TSR files, or as a RAM disk . The AllCard , an add-on memory management unit for XT-class computers, allowed normal memory to be mapped into the 0xA0000-EFFFF address range, giving up to 952 KB for DOS programs. Programs such as Lotus 1-2-3 , which accessed video memory directly, needed to be patched to handle this memory layout. Therefore,

841-401: Was supported. Upper memory blocks can be created by mapping extended memory into the upper memory area when running in virtual 8086 mode . This is similar to how expanded memory can be emulated using extended memory so this method of providing upper memory blocks is usually provided by the expanded memory manager (for example EMM386 ). The application programming interface for managing

#640359