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:
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:
Address size (bits)
Compatibility mode (legacy protected mode)
Virtual 8086 mode
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:
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:
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!
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)
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.
@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.
Your email address will not be published. Required fields are marked.