32 bit code can run in a 64 bit OS, but only in "process" with a 32 bit
virtual address space. That is, 32 bit code uses machine instructions that
use registers with 32 bits to address memory. The 64 bit OS maps this 32
bit virtual memory address into the 64 bit physical memory address using
hardware designed for this purpose - this is part of the virtual memory
implementation in the hardware and OS.
Some hardware drivers need to run in the "real" mode (not necessarily the
"correct technical term") to address the actual hardware and the memory. To
do this, the code must be written to use a 64 bit address in a 64 bit
register and the 64 bit instruction set. If the code only knows about 32
bit registers, the 32 bit instruction set and 32 bit addressess, it will not
work properly in the real, 64 bit, address space - half of the memory
address would be missing so the wrong memory locations would be referenced.
Most programs available today in fact use 32 bit instructions and 32 bit
addresses. Becuase the OS, processor and memory architecture are designed
so this can work, those programs can run in 32 bit virtual memory address
space. As explained above, this is not possible for drivers that have to
operate directly on the hardware without virtual memory address translation.
Conceptually, it might be theoretically possible to design the hardware and
the OS architecture so that the 32 bit instruction set and 32 bit registers
could somehow be mapped into a 64 bit address in the "real" mode (for
example by asuming all 0s or all 1s in the upper 32 bits), but the x64
architecture is not designed that way, so it is not possible with the
Intel/AMD x64 processors and Windows; I suspect it would be just to complex
to make practical. Hardware manufacturer's have to rebuild their drivers to
work in the 64bit systems.
That is one reason that Windows XP 64 bit never really took off - there was
not enough demand for the hardware manufacturers to deliver 64 bit drivers
for Windows XP. Now that essentially all new PCs have 64 bit processors and
64 bit Windows (Vista, Server 2003 and Server 2008) are much more common,
most newer hardware comes with 64 bit drivers. Also, to be eligble for one
of the "Vista" logos (defined by Microsoft), the hardware must have 64 bit
drivers, which is an incentive for the hardware manufacturers.
--
Bruce Sanderson
http://members.shaw.ca/bsanders
It is perfectly useless to know the right answer to the wrong question.
"It's simply the way the architecture works."
Thanks for the reply, Richard. But the curious (perhaps devious) side
of me begs to ask, why is it that way? I understand the difference
between 32 and 64 bits mathematically, but shouldn't there be a way
for a 64 bit architecture to recognize 32 bit code? Perhaps, since
the size of the bit package is getting larger, they could designate
part of the sequence to indicate what bit size the message is being
sent as!
Looking for an engineer to explain this, for those of us in the dark.
In software, backwards compatibility is built into all64-bitversions of
Windows. Most32-bitsoftware will work properly under64-bitWindows.
However, this does not extend to drivers and cannot be made to do
so -64-bitWindows requires64-bitdrivers and there's no way around that.
It's
simply the way the architecture works.
--
Richard G. Harper [MVP Shell/User] (e-mail address removed)
* NEW! Catch my blog ...
http://msmvps.com/blogs/rgharper/
* PLEASE post all messages and replies in the newsgroups
* The Website -http://rgharper.mvps.org/
Can anyone essentially ask this question, which may seem stupid, but
keep in mind this is someone who doesn't understand computer
architecture:
Why can'tbittobitconversions be backward compatible?
Regarding my obsolete musical equipment which does not have drivers
for64-bitprocessing.- Hide quoted text -
- Show quoted text -
