Xylos brands

Legacy 16-bit Applications on 64-bit Operating Systems

Every now and then, we receive the question from a customer whether it is possible to use legacy DOS applications (or other 16 bit applications) on a 64-bit operating system. This happens in a variety of scenarios, for example:

  • Migration project to Windows 7 where the 64-bit architecture is used,
  • Configuration or upgrade towards Citrix XenApp 6, which runs exclusively on Windows Server 2008 R2 and hence provides a 64-bit OS to the applications offered through XenApp.

That the execution of 16-bit applications on a 64-bit Windows OS is not possible, is well known. A common misconception is that this is purely a software limitation (a missing or unreleased Windows component). The true reason is at a much more profound level of the computer and consists of a processor limitation to execute (non-protected mode) 16-bit code.

To understand the origin of this limitation, the evolution of the x86 architecture since its initial release with the 8086 processor in 1978 must be examined. The entire history of the x86 architecture is still visible in the different processor operating modes of a modern x86-64 processor:

OS required
Address size (bits)

Long mode

64-bit mode

64-bit OS

64 bits

Compatibility mode (legacy protected mode)

32 bits

16 bits

Legacy mode

Protected Mode

32-bit OS

32 bits

16 bits

Virtual 8086 mode

16 bits

Real mode

16-bit OS

16 bits

The processor mode determines what the code that is being executed on the processor can or cannot do. For example, all modes except "real mode" prevent applications (code) of writing to memory areas that have not been explicitly assigned to them – a crucial protection in a multitasking operating system environment!

When the computer is turned on, the processor first starts in "real mode"", where no limitations whatsoever exist: every processor instruction can be executed by any application, without any memory protection. The code of the BIOS is executed in this context (which requires full & unlimited access to all of the hardware). Very quickly after that, the boot of the operating system will switch the processor to a higher mode, depending on what the operating system supports:

  •  A 32-bit operating system will switch the processor to "protected mode"", which is one of the legacy modes on a modern x86-64 processor. All the code of Windows applications, the Windows kernel and operating system run in that protected mode. However, at any time, the processor can be switched to the "virtual 8086" mode. This mode is a safe, processor-level emulation of "real mode"", which changes the memory addressing used back to that of the 8086 processor (different from memory addressing in protected mode), and which will emulate some sensitive processor instructions such that they cannot interfere with the other code & memory running in protected mode. This allows the processor to switch back & forth between the 32-bit operating system, and an application still requiring that typical 16-bit environment where it (thinks it) has full control over the processor. We refer to this overview for more information.
  • A 64-bit operating system will switch to "long mode" (the 64-bit mode) in order to immediately have access to the full 64-bit address space. However, once "long mode" has been enabled for the processor and the operating system loaded in this mode, it is not possible to enter one of the legacy processor modes (safely). Therefore, the virtual 8086 mode cannot be used in "long mode"".
  • A 16-bit operating system (such as MS-DOS) is not aware of of higher processor modes, and will execute completely in real mode. Given that every application started by any user has full control over the hardware and memory of the computer, makes multitasking a true challenge in such an environment: it's up to the application developer to behave nicely and write code which is gentle to the system in real mode.This explains why already very early in the operating system history, with Windows 2.1,  the protected mode of the Intel 386 processor is used to step away from granting individual applications full access rights to the system, and to distinguish between critical system code (the kernel) and user-code.

This makes it very clear what limitations the usage of a 64-bit operating system imposes on the use of legacy code: only 16-bit code which runs in protected mode (which can be accessed through the compatibility mode in long mode) can be executed by the processor. Since the majority of DOS applications run in real-mode, a possible solution must be found at the operating system level, since the hardware will not help us in this case.

A first remark is that even for a 32-bit operating system, a lot of work needs to be done to run 16-bit applications in the virtual 8086 mode (such as emulating virtual devices for serial and parallel ports). This work is done by the NTVDM (NT Virtual Dos Machine) components to execute 16-bit code in 32-bit operating systems. NTVDM is a 32-bit Windows application that simulates an Intel 486 computer running MS-DOS. For a full technical explanation, we refer to Microsoft Technet. The NTVDM uses virtual 8086 mode to simulate the 8086's real mode at the processor level.

Since 64-bit long mode only allows protected mode 16-bit applications, the only solution to run real mode 16-bit applications in a modern processor's 64-bit long mode, is to completely emulate the 8086 processor in software. This also meant that with the mainstream introduction of 64-bit Windows operating systems (with Vista x64), Microsoft was facing a challenge: to support legacy DOS applications, the existing NTVDM needed to be extended to do full 8086 processor emulation (with the corresponding performance impact of emulation). Given the abundance of other virtualization & emulation products on the market, it was decided to remove the NTVDM from Windows x64 all together.

On top of that, Microsoft imposes some additional constraints even for 16-bit protected mode programs, which in principle can be executed using the compatibility mode in a long mode processor.  Per Microsoft KB 282423, the only two types of 16-bit protected mode applications that a Windows x64 OS will allow to be executed, are InstallShield and Acme installer files (16-bit installers used to install 32-bit applications).

This discussion shows that, much like running 16-bit code on a 32-bit operating system, also the execution of 32-bit applications on a 64-bit operating system is far from a trivial task, which involves switching the processor mode. This is why 32-bit applications on x64 Windows are executed in a separate environment called "WoW64"", short for "Windows on Windows x64"".

Now that we know the origin of the very limited support for 16-bit applications on Windows x64 operating systems, let's discuss the possible solutions. There are several enterprise-level approaches to circumventing the limitations imposed by the processor on the execution of 16-bit code:

  • Resort to a 32-bit operating system. A 32-bit operating system such as Windows 7 32-bit or Window Server 2008 32-bit, never runs in the processor's long mode and hence still has access to the virtual 8086 mode of the x86 architecture. NTVDM is still included in all the 32-bit operating systems released by Microsoft.
  • Resort to emulation of a 16-bit environment.  Several emulation products are available, such as the well-known DOSBox or Bochs emulators; it is important to realize that many of these emulation solutions are geared towards running older DOS games on modern Windows systems. This also means that application support is often limited and a first example is the lack of printing emulation for DOSBox – one needs to resort to user patches to get a "print-to-file LPT1"": working in a way that also Bochs supports printing. None of these solutions offer enterprise-level support since they are both freeware projects. Furthermore, emulation is not very resource friendly and has a significant impact on processor usage.
  • Resort to virtualization. The only true enterprise-grade workaround for 16-bit applications is to use one of the many forms of virtualization in combination with a client-side x64 operating system:
    • Presentation virtualization can be used to execute 16-bit applications on Windows 2008 (not R2!) which is still available in a 32-bit version and with Extended Support from Microsoft until July 2018. This workaround can be as simple as using RemoteApps on Windows 2008 RDS, or a full-featured Citrix XenApp 5 implementation. This allows to buy some additional time to work away the legacy applications; however, the real problem is only postponed until 2018...
    • Virtual desktops can be used to offer centralized desktops (either based on Windows 7 32-bit, or on Windows XP) specifically for legacy applications. However, this quickly becomes a very expensive solution, given that this involves offering and maintaining two workstations for every legacy application user (one physical workstation and a virtual desktop).
    • Client-side virtualization can also be used to run the legacy applications not in the datacenter (which is the case for virtual desktops or presentation virtualization). In that case, we recommend to investigate the Microsoft Enterprise Desktop Virtualization (MED-V) since this offers a centralized management capability for the legacy images. We do not recommend using Windows 7's XP mode which introduces quite some management challenges. It is also important to realize that virtualization of a 16-bit application or environment on a 64-bit host operating system, also involves emulation (the processor cannot be used directly because it is operating in long mode!), with the corresponding performance impact. The advantage of using a virtualization solution instead of one of the earlier mentioned emulation products is the included centralized management available in a solution such as MED-V.

Also note that application virtualization is not a solution to the 16-bit applications problem for 64-bit operating systems, since the architecture of the operating system is not hidden from the virtualized application (there is no emulation of another operating system or architecture involved when doing application virtualization) – the application will still be started in a 64-bit environment, even when wrapped in a virtual package such as Microsoft App-V or VMware ThinApp!

Share this blogpost

Also interesting for you


Eske Rahn

Thanks for the detailed explanation that still holds five years later.

But as they have made Hyper-V they already got the emulation-system, so why not make a NTVDM variant for the 64-bit system that existed within a sandbox of RAM (say ½GB), and emulated a protected mode and run the NTVDM-32 code emulated?

It seems like a reasonable simple solution to give full backwards compatibility. SURE it will add overhead, but for a legacy app, the modern CPUs seem ‘infinite’ fast anyway, so the overhead would be fully acceptable, and would allow us to ditch the 32-bit windows.


In the lack of a real solution I ‘ended’ up with the rather silly workaround of using Win64 and a Hyper-V virtual machine with a dynamic 32MB virtual disk of vhdx type [*] and PCDOS 6.1 to run the old 16 bit stuff (that runs quite well on 32 bit windows).

[*] Type vhdx disks has the important feature that opening e.g. a shortcut to the file mounts it as a drive, and thus make easy RW file access without fiddling with networks. (It must be ‘ejected’ before ‘turning on’ the virtual machine of course).

(two 2017 comments re-posted)

Vladislav Toncharov

This is not entirely true. The switch from long mode to protected mode (x86_64 -> x86) is possible (can be made safely, including returning to long mode later) and isn't that performance-harming. MS just didn't read the AMD x86_64 manual fully, that's the reason.

Eske Rahn

@Vladislav Toncharov, Interesting that it should be possible, does that go for Intel as well, or AMD only? I guess that MS most likely designed Windows based on Intel specs.

Leave a reply

Your email address will not be published. Required fields are marked.