32 bit to 64 bit compatibility

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't bit to bit conversions be backward compatible?

Regarding my obsolete musical equipment which does not have drivers
for 64-bit processing.

In software, backwards compatibility is built into all 64-bit versions of
Windows. Most 32-bit software will work properly under 64-bit Windows.
However, this does not extend to drivers and cannot be made to do so -
64-bit Windows requires 64-bit drivers and there's no way around that. It's
simply the way the architecture works.

--
Richard G. Harper [MVP Shell/User]
* NEW! Catch my blog ... http://msmvps.com/blogs/rgharper/
* PLEASE post all messages and replies in the newsgroups
* The Website - http://rgharper.mvps.org/


<> wrote in message
news:aebc87c2-514e-4ba3-80d2-...
> 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't bit to bit conversions be backward compatible?
>
> Regarding my obsolete musical equipment which does not have drivers
> for 64-bit processing.

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

On Aug 17, 5:11*am, "Richard G. Harper" <rghar...@email.com> wrote:
> 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] *rghar...@gmail.com
> * NEW! Catch my blog ...http://msmvps.com/blogs/rgharper/
> * PLEASE post all messages and replies in the newsgroups
> * The Website -http://rgharper.mvps.org/
>
> <mitchellren...@gmail.com> wrote in message
>
> news:aebc87c2-514e-4ba3-80d2-...
>
>
>
> > 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 -

"Code" and "Drivers" are two different things. They are loaded differently,
at different times, and have different services available to them. "Code"
can load through the thunking layer that allows 32-bit code to run on the
64-bit platform. "Drivers" cannot. There's simply no way to allow it to
happen.

BTW - I am an engineer. :-)

--
Richard G. Harper [MVP Shell/User]
* NEW! Catch my blog ... http://msmvps.com/blogs/rgharper/
* PLEASE post all messages and replies in the newsgroups
* The Website - http://rgharper.mvps.org/


<> wrote in message
news:ec49eaf2-cbe9-4391-ad28-...
"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.

On Aug 17, 5:11 am, "Richard G. Harper" <rghar...@email.com> wrote:
> 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] rghar...@gmail.com
> * NEW! Catch my blog ...http://msmvps.com/blogs/rgharper/
> * PLEASE post all messages and replies in the newsgroups
> * The Website -http://rgharper.mvps.org/
>
> <mitchellren...@gmail.com> wrote in message
>
> news:aebc87c2-514e-4ba3-80d2-...
>
>
>
> > 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 -

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.



<> wrote in message
news:ec49eaf2-cbe9-4391-ad28-...
"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.

On Aug 17, 5:11 am, "Richard G. Harper" <rghar...@email.com> wrote:
> 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] rghar...@gmail.com
> * NEW! Catch my blog ...http://msmvps.com/blogs/rgharper/
> * PLEASE post all messages and replies in the newsgroups
> * The Website -http://rgharper.mvps.org/
>
> <mitchellren...@gmail.com> wrote in message
>
> news:aebc87c2-514e-4ba3-80d2-...
>
>
>
> > 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 -

I appreciate the responses. If I knew more about how drivers, code,
and addresses worked in the framework of computing, I would be more
intelligible.

There are a lot of people, I imagine, who believe it's a conspiracy,
because every time this happens, it causes a wave of obsolesence with
regard to compatibility. There certainly is anger amongst people who
don't have the money to revinvest in new equpiment. The store manager
at Guitar Center was telling me about the headaches he had trying to
explain to musicians calling the store about problems they were having
when the migration from 16 to 32 bit occurred. And now the same thing
is happening with 32 bit to 64 bit. I've had a manufacturer tell me I
can't run 64 bit and use a piece of their equipment, and at the same
time I've had HP tell me if I installed 32 bit over 64 bit, I'd void
my warranty on a new computer. I bet if you interviewed an ordinary
person on the issue, they would say the main reason is that the
industry is trying to make more money - whether or not that's right or
wrong.

It's inevitable that we're going to move to 128 bit, and then beyond.
I guess I'm still pretty skeptical that it couldn't be done in the
future, but perhaps I'm wrong in thinking that we have the foresight
to predict how new technology is going to change architecture.
Perhaps it's a problem of industry standardization. Or that it just
can't be done. The term "scalability" applies here...creating
platforms which allow for future growth, with full backwards
compatibility. When someone says impossible, it seems like a
challenge!

<> wrote in message news:52019804-3dc7-46b5-98f9-...
>I appreciate the responses. If I knew more about how drivers, code,
> and addresses worked in the framework of computing, I would be more
> intelligible.
>
> There are a lot of people, I imagine, who believe it's a conspiracy,
> because every time this happens, it causes a wave of obsolesence with
> regard to compatibility. There certainly is anger amongst people who
> don't have the money to revinvest in new equpiment. The store manager
> at Guitar Center was telling me about the headaches he had trying to
> explain to musicians calling the store about problems they were having
> when the migration from 16 to 32 bit occurred. And now the same thing
> is happening with 32 bit to 64 bit. I've had a manufacturer tell me I
> can't run 64 bit and use a piece of their equipment, and at the same
> time I've had HP tell me if I installed 32 bit over 64 bit, I'd void
> my warranty on a new computer. I bet if you interviewed an ordinary
> person on the issue, they would say the main reason is that the
> industry is trying to make more money - whether or not that's right or
> wrong.
>
> It's inevitable that we're going to move to 128 bit, and then beyond.
> I guess I'm still pretty skeptical that it couldn't be done in the
> future, but perhaps I'm wrong in thinking that we have the foresight
> to predict how new technology is going to change architecture.
> Perhaps it's a problem of industry standardization. Or that it just
> can't be done. The term "scalability" applies here...creating
> platforms which allow for future growth, with full backwards
> compatibility. When someone says impossible, it seems like a
> challenge!


Just a thought, but, don't some of the virtual machine soft wares emulate 32-bit driver support? So then, if virtual pc software
were installed on Vista64, one may (or may not) have the good fortune to run some 32 bit soft wares with the intervening virtual
machine software layer translating the 32-bit driver requests into 64-bit requests of the OS?

If you want to run the 32-bit programs with 32-bit drivers you would have to
install a 32-bit OS in the Virtual Machine

"B. D. Reagan" <> wrote in message
news:...
> <> wrote in message
> news:52019804-3dc7-46b5-98f9-...
>>I appreciate the responses. If I knew more about how drivers, code,
>> and addresses worked in the framework of computing, I would be more
>> intelligible.
>>
>> There are a lot of people, I imagine, who believe it's a conspiracy,
>> because every time this happens, it causes a wave of obsolesence with
>> regard to compatibility. There certainly is anger amongst people who
>> don't have the money to revinvest in new equpiment. The store manager
>> at Guitar Center was telling me about the headaches he had trying to
>> explain to musicians calling the store about problems they were having
>> when the migration from 16 to 32 bit occurred. And now the same thing
>> is happening with 32 bit to 64 bit. I've had a manufacturer tell me I
>> can't run 64 bit and use a piece of their equipment, and at the same
>> time I've had HP tell me if I installed 32 bit over 64 bit, I'd void
>> my warranty on a new computer. I bet if you interviewed an ordinary
>> person on the issue, they would say the main reason is that the
>> industry is trying to make more money - whether or not that's right or
>> wrong.
>>
>> It's inevitable that we're going to move to 128 bit, and then beyond.
>> I guess I'm still pretty skeptical that it couldn't be done in the
>> future, but perhaps I'm wrong in thinking that we have the foresight
>> to predict how new technology is going to change architecture.
>> Perhaps it's a problem of industry standardization. Or that it just
>> can't be done. The term "scalability" applies here...creating
>> platforms which allow for future growth, with full backwards
>> compatibility. When someone says impossible, it seems like a
>> challenge!
>
>
> Just a thought, but, don't some of the virtual machine soft wares emulate
> 32-bit driver support? So then, if virtual pc software were installed on
> Vista64, one may (or may not) have the good fortune to run some 32 bit
> soft wares with the intervening virtual machine software layer translating
> the 32-bit driver requests into 64-bit requests of the OS?
>
>
>

That depends - for example, if the "obsolete musical equipment" connects via
USB, it might not work with a virtual machine because not all VM systems
support USB devices in guest virtual machines.

VMWare says that VMWare Workstation 4.5 does support USB devices, but not
all devices all necessarily work - see
http://www.vmware.com/support/ws45/d...es_usb_ws.html. I have never
used VMWare Workstation.

Parallels also say they support USB devices in virtual machines
http://www.parallels.com/en/products/workstation/.

There are also some third party solutions that purport to allow virtual
machines to use USB devices (haven't tried any)
For example:
http://www.usb-over-network.com/usbn...s/virtual.html

If it connects via a serial port, it might work.

--
Bruce Sanderson
http://members.shaw.ca/bsanders/
It's perfectly useless to know the right answer to the wrong question.


"B. D. Reagan" <> wrote in message
news:...
> <> wrote in message
> news:52019804-3dc7-46b5-98f9-...
>>I appreciate the responses. If I knew more about how drivers, code,
>> and addresses worked in the framework of computing, I would be more
>> intelligible.
>>
>> There are a lot of people, I imagine, who believe it's a conspiracy,
>> because every time this happens, it causes a wave of obsolesence with
>> regard to compatibility. There certainly is anger amongst people who
>> don't have the money to revinvest in new equpiment. The store manager
>> at Guitar Center was telling me about the headaches he had trying to
>> explain to musicians calling the store about problems they were having
>> when the migration from 16 to 32 bit occurred. And now the same thing
>> is happening with 32 bit to 64 bit. I've had a manufacturer tell me I
>> can't run 64 bit and use a piece of their equipment, and at the same
>> time I've had HP tell me if I installed 32 bit over 64 bit, I'd void
>> my warranty on a new computer. I bet if you interviewed an ordinary
>> person on the issue, they would say the main reason is that the
>> industry is trying to make more money - whether or not that's right or
>> wrong.
>>
>> It's inevitable that we're going to move to 128 bit, and then beyond.
>> I guess I'm still pretty skeptical that it couldn't be done in the
>> future, but perhaps I'm wrong in thinking that we have the foresight
>> to predict how new technology is going to change architecture.
>> Perhaps it's a problem of industry standardization. Or that it just
>> can't be done. The term "scalability" applies here...creating
>> platforms which allow for future growth, with full backwards
>> compatibility. When someone says impossible, it seems like a
>> challenge!
>
>
> Just a thought, but, don't some of the virtual machine soft wares emulate
> 32-bit driver support? So then, if virtual pc software were installed on
> Vista64, one may (or may not) have the good fortune to run some 32 bit
> soft wares with the intervening virtual machine software layer translating
> the 32-bit driver requests into 64-bit requests of the OS?
>
>
>