47

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 16-bit Windows applications.

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

Franck Dernoncourt
  • 24,246
  • 64
  • 231
  • 400

6 Answers6

32

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.

Matt Sieker
  • 596
17

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.

Community
  • 1
user541686
  • 23,629
11

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 the following Microsoft article about lack of 16-bit support: https://learn.microsoft.com/en-us/troubleshoot/windows-client/application-management/x64-windows-not-support-16-bit-programs

Update: Micrsoft seems to have added some 16-bit emulation back into modern versions of Windows, albeit in the form of an emulator/VM. Maybe modern Virtualization has made this easier, but interesting choice: https://www.groovypost.com/howto/enable-16-bit-application-support-windows-10/

SqlRyan
  • 1,123
6

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.

plugwash
  • 6,719
3

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: http://en.wikipedia.org/wiki/Long_mode, 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.

MichaelS
  • 199
2

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.

Stephen C
  • 445