Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Why is it that:

  • a 32-bit OS, when installed on a 64-bit CPU, can run old 16-bit applications,
  • but if you install a 64-bit OS it can't run those applications directly and need some sort of emulation (that doesn't always work perfectly)?

To be more specific, I have an 64-bit processor (Intel Core 2 Duo). When I had Windows XP and Windows 7 (both 32-bit) installed, they could run old DOS and 616-bit Windows applications.

Now I have installed the 64-bit edition of Windows 7. Why can't it run those same applications anymore?

share|improve this question

migrated from May 14 '10 at 0:34

This question came from our site for professional and enthusiast programmers.

I think that has less to do with the bits and more with the guest operating system. What OS's are you referring to specifically? – Pekka 웃 May 13 '10 at 14:40
Will it run under DOSBox? – Penguat May 13 '10 at 15:30
There is a utility called DOSBOX its a 16 bit emulator that gives your 16 bit program a virtual 16 bit computer to work on, and its free. – user114474 Jan 20 '12 at 4:22
I agree with Pekka, the fact is that a 64-bit (hardware) system can run 16-bit code (heck, even 1-bit code if the OS were so designed). The real catch is that the CPU cannot directly run the 16-bit code due to things like different pointer sizes, but these issues can be abstracted away by the OS. The limitation is an artificial one that Microsoft imposed to simplify things (though they still emulated 32-bit because there is still so much 32-bit code). There are other OSes (*nix?) that can run 16-bit code without issue. – Synetech Sep 1 '12 at 20:59

From my understanding, it's because when running in Long Mode (x64 native), the CPU itself doesn't support going into 16 bit mode. See Wikipedia. So, in order to support 16 bit mode, the NTVDM (the 16 bit layer in Windows) would have to fully emulate a 16 bit processor.

I suppose they weighed re-implementing an emulation layer vs using already extant virtualization software (VirtualPC, VirtualBox) to handle this, and it was decided to cut the VDM.

share|improve this answer
Quoting from Wikipedia: Versions of Windows NT for 64-bit architectures (x64 and IA-64) do not include the NTVDM and are unable to run DOS or 16-bit Windows applications. This is because, in an x86-64 CPU, virtual 8086 mode is available as a sub-mode only in its legacy mode (for running 16- and 32-bit operating systems), not in the native, 64-bit long mode; a hard reset of the CPU is required to switch to legacy mode. So the only way how NTVDM has worked so far isn't available anymore and full VMs are out there aplenty, so NTVDM was cut. – Joey May 14 '10 at 6:57
Yuck, I can't believe they dumped the V86 mode. Might as well toss real mode completely and demand 32/64 bit boot loaders if you're going to do that. – Brian Knoblauch Jul 23 '10 at 18:50
That is exactly what has already happened, M. Knoblauch. A modern x86 machine with EFI firmware goes straight from unreal mode in its first few instructions to 64/32-bit protected mode. The boot loaders are indeed 64/32-bit protected mode programs. That's what EFI boot applications are. There's no use of real mode or v8086 protected mode anywhere in the process. – JdeBP Jan 20 '12 at 8:41
-1. WINE supports running 16-bit Windows apps in VM86 mode on 64-bit Linux. screenshot. V86-64 Project page. Mehrdad's answer seems like the more compelling reason. – Hugh Allen Dec 15 '12 at 0:36
@HughAllen: that page currently says "Currently 64-bit version of linux kernel lacks support of V86 mode because it is not supported in native operating mode (long mode) of these processors." and "This patch is very experimental." The short answer is that although it is possible to run 16-bit code, by exiting long mode completely, it isn't sensible to do so. – Harry Johnston Oct 15 '13 at 3:41

Because 64-bit handles have 32 significant bits:

Note that 64-bit Windows does not support running 16-bit Windows-based applications.
The primary reason is that handles have 32 significant bits on 64-bit Windows.
Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data.

In Windows, programs pass around "handles" to the OS and vice-versa (which are numbers that the OS uses to uniquely identify a particular resource, such as a window).

To support 16-bit programs, 32-bit Windows only generates a handles that have 16 significant bits -- the 16 upper bits are ignored by the OS (even though programs are not to be taking advantage of this fact). So no program can interact with more than 216 objects, which is actually rather low.

However, in order to improve this, 64-bit Windows increased the number of significant bits in a handle to 32. But now that means that handles cannot be passed to 16-bit programs without loss of information. So 16-bit programs cannot run on 64-bit Windows.

share|improve this answer
Why was this downvoted? – Mehrdad Jul 22 '12 at 6:45
Probably because the reason refers to 16-bit Windows applications while the question was about 16-bit DOS applications. – Joey Dec 14 '12 at 6:16
@Joey: I don't understand what you're saying. If the OS is 64-bit Windows, then 16-bit applications can't run on it, period. I don't see how the fact that they're "DOS" or "Windows" application changes anything here -- either way, handles would need to be truncated by the application. – Mehrdad Dec 14 '12 at 6:19
... actually, even Win16 code shouldn't be too much of a problem, now that I think about it. All you'd need is a lookup table. – Harry Johnston Oct 15 '13 at 3:52
I was talking about kernel handles as per the article, not window handles. They're completely different things. Do 16-bit applications even see 32-bit windows? It seems unlikely, because the message structures are different; what would happen if a 16-bit app was sent a message with a 32-bit wParam? Also, note that the maximum number of window handles is still 2^16 according to… – Harry Johnston Oct 15 '13 at 21:32

For Windows, it's because the x86 versions of the OS includes 16-bit emulation that allows them to run those older DOS processes. In the x64 versions, they already have to emulate x86 execution (they call it WoW64) to allow 32-bit processes to run, and I guess using Wow64 to further emulate the 16-bit emulator caused too many problems.

A handful of recognized 16-bit processes will run because the emulation is hard-coded to handle them, but the rest don't work because emulation isn't included in x64.

See "No 16-bit code" at the MSKB article:

share|improve this answer
There's no emulation going on - x86/64 can run these things natively. There is API thunking going on however. Microsoft has chosen this opportunity to retire a significantly old and mostly unused technology. – darthcoder May 13 '10 at 14:53
@Chris Kaminski - I'm surprised that they'd do that as an architecture decision - x86 vs x64 - as opposed to saying "Alright - it's Windows 7, and we're not running 16-bit processes anymore". Especially with "Windows XP Mode" now embedded in 7, it seems like the perfect time to cut support even in the x86 version. – SqlRyan May 13 '10 at 17:31
@Chris Kaminski: After giving it some more thought, I think it has to be emulating it, not just some kind of API-mucking. If it could run code of a different bit-build natively, then why would x64 have Wow64 to run 32-bit apps - wouldn't those run natively as well? – SqlRyan May 13 '10 at 21:34
@darthcoder: The CPU simply doesn't support the virtual 8086 mode required by NTVDM in long (64 bit) mode. Therefore either NTVDM would have to become a full VM, emulating everything or get cut. Since there are enough VMs out there already (and MS has one too) that wasn't a hard decision. I don't think it has anything to do with how old that was or how much used. – Joey May 14 '10 at 7:01
rwmnau: For WoW64 there is no emulation going on (except for Itanium). x64-64 CPUs still support the 32-bit instructions so almost all Windows has to do is switch the CPU in 32-bit mode and mess with a few pointers. – Joey May 14 '10 at 7:04

I think that the most likely reason is that only a tiny percentage of PC owners actually want to be able to run old 16 bit applications on their new 64 bit hardware. Microsoft probably figured that it wasn't worth their while continuing to support 16 bit applications.

share|improve this answer
This makes sense except for Windows 7 32bit still supports it, so apparently it's worth it to use what they already have but not reimplement it(as would be needed for x86-64 due to no virtual-8086 mode – Earlz May 14 '10 at 1:09
I was thinking that "we don't want to maintain a complicated code base". If they kept in 16-bit, they might have had to support software that dates back to the 80s. This may include putting in ugly hacks so that Lotus 1-2-3 still works. – Joe Plante Aug 9 '15 at 20:25

Correct me if I'm wrong, but to my understanding it is just because of Windows-specific problem that NTVDM is using virtual 8086 mode. Compatibility mode on x64 processors (running in long mode) supports full 'clean' protected mode, 16 and 32 bit from what I've found here:, but not some of the 386 additions such as virtual 8086 mode. So it is not supported most likely because it doesn't pay off for Microsoft to reprogram NTVDM, which would probably require adding some more emulation because some 16-bit protected mode applications can use virtual 8086, even if most do not. I suppose with enough labor it is possible to write something faster than dosbox running in long mode, since there is hardware support for 16bit apps.

share|improve this answer

The situation is different for Dos applications and 16 bit windows applications.

For Dos applications the problem is that virtual 8086 mode is not available under long mode. This is a CPU architecture limitation.

For 16 bit Windows appliations (which run in 16 bit protected mode) the reason is that MS wasn't prepared to do the work to implement a suitable compatibility layer. Amusingly Wine is perfectly capable of running 16 bit windows apps on 64-bit linux.

share|improve this answer

protected by nhinkle Feb 2 '15 at 9:30

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?