Editing Conventional memory (section)

== DOS extenders ==
<!-- http://support.microsoft.com/kb/95555 describes the use of BIOS Interrupt 15 services to allocate extended memory. OS2 etc. interpreted BIOS IRQ 15 incorrectly over 64 MB so newer systems had setup to bypass this -->
The barrier was only overcome with the arrival of [[DOS extender]]s, which allowed DOS applications to run in 16-bit or 32-bit [[protected mode]], but these were not very widely used outside of [[PC game|computer gaming]]. With a 32-bit DOS extender, a game could benefit from a 32-bit flat address space and the full 32-bit instruction set without the 66h/67h operand/address override prefixes. 32-bit DOS extenders required compiler support (32-bit compilers) while [[XMS (memory management)|XMS]] and [[Expanded memory|EMS]] worked with an old compiler targeting 16-bit real-mode DOS applications. The two most common specifications for DOS extenders were [[VCPI]]- and later [[DOS Protected Mode Interface|DPMI]]-compatible with Windows 3.x.

The most notable DPMI-compliant DOS extender may be [[DOS/4G|DOS/4GW]], shipping with [[Watcom C/C++|Watcom]]. It was very common in games for DOS. Such a game would consist of either a DOS/4GW 32-bit kernel, or a stub which loaded a DOS/4GW kernel located in the path or in the same directory and a 32-bit "linear executable". Utilities are available which can strip DOS/4GW out of such a program and allow the user to experiment with any of the several, and perhaps improved, DOS/4GW clones.

Prior to DOS extenders, if a user installed additional memory and wished to use it under DOS, they would first have to install and configure drivers to support either [[expanded memory]] specification (EMS) or [[extended memory]] specification (XMS) and run programs supporting one of these specifications.

EMS was a specification available on all PCs, including those based on the [[Intel 8086]] and [[Intel 8088]], which allowed add-on hardware to page small chunks of memory in and out ([[bank switching]]) of the "real mode" addressing space (0x0400–0xFFFF). This allowed 16-bit real-mode DOS programs to access several megabytes of RAM through a hole in real memory, typically (0xE000–0xEFFF). A program would then have to explicitly request the page to be accessed before using it. These memory locations could then be used arbitrarily until replaced by another page. This is very similar to modern paged [[virtual memory]]. However, in a virtual memory system, the operating system handles all [[paging]] operations, while paging was explicit with EMS.

XMS provided a basic protocol which allowed a 16-bit DOS programs to load chunks of 80286 or 80386 extended memory in low memory (address 0x0400–0xFFFF). A typical XMS driver had to switch to protected mode in order to load this memory. The problem with this approach is that while in 286 protected mode, direct DOS calls could not be made. The workaround was to implement a callback mechanism, requiring a reset of the 286. On the 286, this was a major problem. The [[Intel 80386]], which introduced "[[virtual 8086 mode]]", allowed the guest kernel to emulate the 8086 and run the host operating system without having to actually force the processor back into "real mode". [[HIMEM.SYS]] 2.03 and higher used [[unreal mode]] on the 80386 and higher CPUs while HIMEM.SYS 2.06 and higher used [[LOADALL]] to change undocumented internal registers on the 80286, significantly improving interrupt latency by avoiding repeated real mode/protected mode switches.<ref name="Loadall"/>

Windows installs its own version of HIMEM.SYS<ref name="Microsoft_95555"/> on DOS&nbsp;3.3 and higher. Windows HIMEM.SYS launches 32-bit protected mode XMS (n).0 services provider for the Windows Virtual Machine Manager, which then provides XMS (n-1).0 services to DOS boxes and the 16-bit Windows machine (e.g. DOS&nbsp;7 HIMEM.SYS is XMS&nbsp;3.0 but running 'MEM' command in a Windows&nbsp;95 DOS window shows XMS&nbsp;2.0 information).