Atmapuri said:
I only wanted to say, that if Intel can maintain x86 compatibility for
30 years!!!
Microsoft could do it also. I see no technical limitations
why 8bit apps could not run on future 256bit systems.
The limitation comes from a specific combination of hardware and software.
32-bit Intel CPUs (and AMD clones) operate in 3 modes: 16-bit Real Mode;
Protect Mode; and V86 Mode. Protect Mode is the "normal" 32-bit mode we all
know and love. V86 is a set of instructions in the IA32 architecture, which
allow multiple virtual, 16-bit x86 machines to be created in memory, running
"alongside" the 32-bit Protect Mode system.
When 16-bit applications run on 32-bit Windows, they run on top of a Windows
component called NTVDM.EXE, or "NT Virtual DOS Machine". The NTVDM is a
complete emulated DOS machine, with DOS operating system, its own 1MB memory
space, etc - in which the 16-bit application will execute. Look at the Task
List before, and while, you run a 16-bit app on 32-bit Windows; you'll see
that NTVDM appears in the list of processes while the 16-bit app is active.
Back in NT days, Microsoft chose to implement the NTVDM using Intel's V86
instructions, because this was by far the most efficient method of
virtualisation. There are other ways to emulate a x86 machine, but they do
not perform as well.
When AMD and Intel released the x64 Architecture (aka EM64T), a new mode was
introduced: 64-bit Mode. When you run a 64-bit Operating System (Windows,
Solaris, Linux etc) on a 64-bit CPU, the processor goes into 64-mode. If you
run a 32-bit OS, the processor stays stuck in Protect Mode.
It is a limitation of 64-bit Mode in the Intel/AMD hardware, that the V86
instructions are no longer available. So, you cannot have V86-based Virtual
DOS Machine on a 64-bit OS. Since Microsoft's NTVDM made heavy use of V86
instructions, it cannot run on 64-bit Windows. Therefore, you cannot run
16-bit applications directly on 64-bit Windows.
You can (in theory) run 16-bit instructions directly on the CPU, while it is
in 64-bit mode - but, not if the code contains V86 instructions. These just
don't exist in 64 bit mode. Also, the 16-bit code must also run in Protect
Mode, which cuts out nearly all existing 16-bit apps out there.
As other posters have noted, there are a couple of workarounds. Basically
they are all forms of x86 emulation, which do not use V86 instructions.
These are somewhat slower than the classic NTVDM; but given current
processing power and the computing requirements of most 16 bit apps, this is
usually not a problem. Microsoft's canonical solution is to use Virtual PC,
and install an MS-DOS or Windows 3.x Virtual Machine. Virtual PC is a free
add-on from Microsoft.
Another approach which works very well is to run DosBox, a 3rd party, open
source project:
http://dosbox.sourceforge.net/news.php?show_news=1
If you're wondering why Microsoft didn't re-write the NTVDM as a
non-V86-using app, well ... they could have; but they already had Virtual
PC, so they had a ready solution anyway.
No current processors run 8-bit instructions natively - not Intel, SPARC,
MIPS, PowerPC or ARM (that covers 99% of the market). Any 8-bit processing
is done in an emulator, like a Commodore 64 emulator. This is loosely the
same principle as DosBox.
Hope that makes it clearer,
