The DOS memory management:
This file describes DOS memory management only in very rough terms.
Anything else would fill an entire book. So I beg your pardon if
you do not find details.
There are other documentations about DOS memory management, e.g.
Search for DOS memory management with your favourite Search engine.
NORMAL low DOS memory:
NORMAL low DOS memory is at most 640 kB. Sometimes minus EBDA which
is an extra BIOS data area, see SWITCHES /E Option to manipulate if
you know what you are doing.
UMB - upper memory blocks:
UMB upper memory blocks, which are the area between 640 kB and 1 MB
accessible by all 8086 or newer CPU in theory, but reserved for VGA
RAM, BIOS and similar in practice. Drivers like RDOSUMB, HIRAM or URAM
can activate normal RAM in unused areas between those in chipset-
dependent ways on various mainboards and all sorts of EMM386 style
drivers can make RAM visible in those areas if you have 386 or newer
CPU. Sometimes, UMB have limitations such as not working with DMA for
floppy or harddisk. Extra drivers bundled with the UMB drivers, or
extra options for EMM386 can be used to work around or try to work
around the limitations. Sometimes you just want to avoid to load
certain disk, network or USB drivers to UMB instead. You can tell the
FreeDOS kernel to move some data structures to UMB with DOSDATA=... and
you can use DOS=... to move some other kernel things to UMB. See also
HMA - high memory area:
HMA high memory area is 64 kB big and starts where the first 1 MB ends.
You can use it on 286 or newer CPU, usually by loading HIMEM or similar
drivers. You can use DOS=... to move large parts of the kernel to HMA.
Other drivers can use remaining HMA space, but this is not done as
easily in FreeDOS as in other DOS. See also FILESHIGH. Because the
accessbility of HMA depends on the infamous A20 address line gate,
you may have to help HIMEM or EMM386 to treat that properly if auto-
detection has resulted in wrong A20 handling.
XMS - extended memory:
XMS extended memory is what HIMEM and similar drivers give you. Note
that JEMMEX is a driver containing both EMM386 and HIMEM in a single
driver. XMS are memory areas which you can ask the driver to copy to or
from DOS memory (or UMB, maybe even HMA) as needed. Protected mode apps
can also access XMS directly at the original location beyond 1 MB after
telling HIMEM to lock areas so they keep a constant absolute location.
You need 286, with common drivers even 386 or newer CPU to use XMS.
EMS - expanded memory area:
EMS expanded memory is what EMM386 usually gives you, but there also
are chipset-dependent hardware drivers for certain old mainboards with
hardware EMS support and there were hardware expansion cards for EMS
for really old computers. Either way, EMS consists of originally 16 kB,
later 4 kB sized pieces of memory which you can make visible (map) at
locations below 1 MB. For the 4 kB style, you need EMS 4, the 16 kB
style is EMS 3.2 and the latter also is limited to make the 16 kB
chunks visible in any quarter of a 64 kB page frame at a location which
has to be a multiple of 64 kB. That page frame takes away space which
you could otherwise use for UMB, so there is a misleadingly named NOEMS
option for EMM386 style drivers which actually means that you need no
page frame. You can still map 4 kB to various multiples of 4 kB within
the first megabyte if you use EMS 4 even when your EMM386 is in NOEMS
mode and has no fixed page frame. Because you make memory appear at
other places instead of actually copying it, EMS can fast when you want
to swap around memory areas, maybe for handling libraries or background
music data in a game, in situations where you do not want to copy a
specific part of your data, but want a whole subset of your data to be
available in case you want to use it. XMS, on the other hand, is good
when you already know which specific data area you want to be copied
where, because you do not have to take the extra step of mapping there.
VCPI is a low-level interface for EMM386 which lets it co-exist with
other protected mode software, so it also involves memory mapping and
allocation. It is not very popular outside DOS Extenders, I would say.
Note that Windows can be called a DOS Extender in this context.
DPMI is a more high-level interface to manage memory in a protected
mode context. It is so comfortable that the CWSDPMI DOS Extender
basically just makes sure that you get DPMI, if necessary distilled
from a number of other (!) types of memory access available in pure
DOS, because apps compiled with DJGPP and similar compilers already
feel fine with DPMI as a DOS Extender, roughly speaking. Windows also
provides DPMI to apps, but not for example VCPI, because the latter
would be too low-level for smooth coexistance with apps directly using
DOS Extenders make sure that apps can use more than 1 MB of memory
taken from any suitable source of memory, using protected mode. So they
may differ a lot in which types of memory they support or not.
This also involves INT15 memory, which is a BIOS based way to access
memory above 1 MB which is not otherwise relevant to most DOS apps,
because they prefer to use the more DOS specific types of memory
instead. So INT15 is more something relevant for HIMEM and EMM386 to
either use or coexist with. In general, the BIOS has provided a number
of different methods to get to know which memory and where is available
for which purposes, often INT15 related, so DOS memory drivers like
HIMEM have to take care to query the newest available sub-method and
they may have to resolve ambiguities and contradictions if the BIOS is
not properly designed.
Note that very specific DOS Extenders can also make it possible for
apps to use more than 4 GB of RAM or more than 1 CPU core. Neither are
widespread yet, so most implementations of HIMEM or EMM386 will be
limited to between 2 GB and 4 GB of usable RAM even if you have more
installed, because things like graphics memory or MMIO areas and extra
BIOS stuff etc. will block some amount of memory within the first 4 GB.
In particular graphics RAM windows can be quite large with modern
graphics hardware and few apps or drivers for DOS take the effort to
use 36- or 64-bit addressing to reach beyond the first 4 GB. You can
assume that the system RAM which you cannot access below 4 GB because
graphics RAM uses the address space will be made available at some
place above 4 GB, so 64-bit aware drivers can use all your RAM. This is
similar to the UMB problem mentioned above, RAM covered by BIOS or by
VGA RAM and therefore not available for UMB can sometimes still be made
available at another address for other purposes such as EMS depending
on your hardware and drivers.
(Comment by Rugxulo:)
8086 could address 1 MB (conventional memory), but the IBM PC specifi-
cally (contrary to SCP's boards) would only use 640 kb (minus OS over-
head) with ROM data (e.g. BIOS) in higher parts. EMS with bankswitching
was optional, but some people (e.g. Jim Leonard) have physical hardware
EMS, allowing a few extra MB.
XMS required an AT, i.e. an 286 on a 286 mainboard. The 286 could only
address 16 MB (or 1 GB virtual, allegedly, IIRC). It fragmented a bit
worse than EMS.
EMM386 was optional but helped get old EMS apps to work using V86 mode.
VCPI (ring 0, 386 only) was a superset of this, supported by Win 3.x
Standard mode (win.com /s), but DPMI was overall better.
DPMI was originally invented for Win 3.0 (Enhanced mode) in 1990 but
later standardized and became common elsewhere (OS/2 2.1, Novell DOS 7).
Unfortunately, most people only supported the 0.9 spec (usually for
32-bit apps only). But Borland did support 16-bit DPMI. So, just to be
clear, unlike ring 0 32-bit exclusive VCPI, DPMI could also be ring 3
and either 286 or 386 compatible. Ring 3 is less prone to OS insta-
There are various bugs and limits in implementations of all of the
above. Testing is more important than blind fidelity to specs.
(Comment by bretjohn:)
What types of memory you may actually need to configure in FreeDOS at
boot time depends on what programs you are going to run and what kind(s)
of memory they use.
Normal low DOS memory
Copyright © 2024 Eric Auer, help version W. Spiegl.
This file is derived from the FreeDOS Spec Command HOWTO.
See the file H2Cpying for copying conditions.