why 32 bit drivers do not work on 64 bit

Question

From past readings it seems most 32 bit drivers won't work on 64 bit.

At a purely conceptual level, I see a 64 bit machine as having extra 'room' when using 32 bit drivers so am trying to determine why most often they will not work. (me coming from user-space)

I have read this wiki article on x86-64 which states

Pushes and pops on the stack are always in 8-byte strides, and pointers are 8 bytes wide.

I can see this perhaps being a reason a 32bit driver might fail on 64bit as it issues a pop() which pops twice as much data as the driver expected.

What I just mentioned may be completely off the mark as I am a user-space guy, in which case, or otherwise, what are some practical examples (code or layman explanation) of why 32 bit drivers fail when run on 64 bit?

Solution 1

Put simply, you can't store a 64-bit address in a 32-bit pointer. So if your code involves passing pointers back and forth to the operating system, as device drivers typically do, it's not going to end well.

Drivers are often about moving data between phyiscal devices (eg, a disk) and memory. The driver will be asked to transfer X disk sectors into memory at address Y.

On a 64-bit OS, Y will be a 64 bit address, so your 32-bit driver can't handle this. And of course there's the issue that the size of the pointer passed is twice what it expects, so if it DID run it would probably stamp all over the wrong memory...

Solution 2

Remember that drivers are there to talk to hardware. What if the 32bit driver code was loaded into a memory area that's more than 4gigabytes away from where the hardware's memory-mapped registers are? The driver code would be scribbling in memory that has nothing to do with itself or the hardware it's supposed to be driving.

Solution 3

x86-64 processors can't run 32 bit code in privileged (kernel) mode. The compatibility mode is only available for user space.

Solution 4

My 2 cents worth. Microsoft doesn't give a rats about the mess it causes when releasing upgrades or patches.

Especially about Legacy hardware being compatible with x64 generation OS's. I'm talking here about the myriad of scientific hardware out there that only has 32bit drivers with that hardware being unobtainable and unsupported any longer, thus leaving Labs running XP or at best 7 x86. Likewise consumers how have bought Biometric scanners and various medical equipment.

The x64 path should have been designed to accommodate legacy 32bit hardware.

View more solutions

Comments

[wal]

if the driver was marked (somehow) as 32bit and only loaded into the addresses less than 4gigs, how would that fare?

[Marc B]

32bit code would still be run in 32bit mode. It wouldn't magically be translated into 64bit mode. It's essentially the same situation as 16bit code running in virtual86 mode on a 32bit 386+ processor. The overall environment is 64bit, but the 32bit portions run in a 32bit sandbox.

[wal]

sure, but it would still run. (allbeit in 32 bit mode)

[wal]

so the driver might ask for some memory allocation to which the OS would return an address that it (the driver) can't address/point-to ?

[Marc B]

Well, think of the situation of a 64bit app calling a hard-drive driver to write out a file, and providing a pointer to some data that's physically at the 5gigabyte point in the system. Without a huge amount of background processing, that data is inaccessible to the driver. A 32bit driver may run, but would be uber-slow to the point of uselessness.

[wal]

@Marc, could you elaborate on a hardware memory-mapped register or provide a link describing more wrt to your answer

[Marc B]

easy one: your graphic card's memory. That gets mapped into the system's memory somewhere so you can talk directly to the card's memory in exactly the same manner as you would address something in system memory. The same can be done with registers so you can use mov instead of in and out assembler instructions.

[LocoDelAssembly]

Actually they can, and has been put in practice in MacOS X 10.5, where although you run 64-bit apps (without emulation), the kernel is 32-bit.

[Axel Gneiting]

They are running a 32 bit kernel and switching to 64 bit on user space. That's different from running 32 bit drivers in a 64 bit kernel.