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.
  Wikipedia, see:
  https://en.wikipedia.org/wiki/DOS_memory_management  OR:
  https://blogsystem5.substack.com/p/from-0-to-1-mb-in-dos OR:
  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
  FILESHIGH.

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:

  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:

  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
  that.

DOS Extenders:

  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.

Comments:

  (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-
  bility.

  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.

The DOS memory management:

NORMAL low DOS memory:

UMB - upper memory blocks:

HMA - high memory area:

XMS - extended memory:

EMS - expanded memory area:

VCPI:

DPMI:

DOS Extenders:

Comments:

See also: