Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 18 down vote favorite
8

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 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 Intel Core 2 Duo (64 bit) processor, and I had Windows Xp and Windows 7 (both 32 bit) installed and it could run old DOS applications, but now that I have installed Windows 7 64 bit it can't run those same applications anymore?

share|improve this question
3  
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

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

5 Answers

up vote 15 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.

share|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
3  
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 '12 at 8:41
show 6 more comments
up vote 7 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

share|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. – 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
up vote 4 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.

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
DOS applications have no handles. In fact, they (usually) don't even know they're running on Windows. – Joey Dec 14 '12 at 6:20
@Joey: The EXE or COM file itself is irrelevant; the "application" is more than just the executable. DLLs/modules are there too. The (user-mode) WOW emulator (NTVDM) is also part of the application, and it does need handles, no? – Mehrdad Dec 14 '12 at 6:20
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.

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
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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.