up vote 11 down vote favorite
4
share [g+] share [fb]

Why is it that a 32 bit OS that is installed on a 64 bit CPU can run old DOS 16 bit applications, but if you install a 64 bit OS it cant run those applications directly and need some sort of emulation (that doesn't always work perfectly)?
To be more specific I have an Intel Core 2 Due (64bit) procesor, and I had Windows Xp and Windows 7 (both 32bit) installed and it could run old dos applications, but now that I have installed Windows 7 64 bit it can't run those same application anymore?

link|improve this question
2  
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
feedback

migrated from stackoverflow.com May 14 '10 at 0:34

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

6 Answers

up vote 13 down vote

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.

link|improve this answer
As i understand it, 16-bit protected-mode code will run in long mode, but real-mode and virtual-8086 mode code won't. And 16-bit code in Windows is run in virtual 8086 mode. – cHao May 13 '10 at 18:21
@cHa 16 bit windows executables are ran in 16-bit protected mode I believe, but he is concerned with a DOS executable which expects real/virtual-8086 mode. – Earlz May 14 '10 at 1:07
2  
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
2  
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
1  
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 at 8:41
feedback
up vote 5 down vote

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: http://support.microsoft.com/kb/282423

link|improve this answer
8  
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. – rwmnau 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? – rwmnau 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
feedback
up vote 1 down vote

Because 64-bit handles have 32 significant bits.

In Windows, programs pass around "handles" to the OS and vice-versa (which are numbers that the OS uses to 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.

link|improve this answer
feedback
up vote 0 down vote

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.

link|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
feedback
up vote 0 down vote

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.

link|improve this answer
feedback
up vote 0 down vote

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.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard