Why aren't there universal 32->64 bit driver translator/emulators?

August 23, 2008 3:37 PM

Why aren't there universal 32->64 bit driver translator/emulators?

64 bit versions of Windows require 64 bit drivers for printers, scanners and other devices. Many people upgrading to a 64 bit computer have had to retire perfectly good hardware simply because of lack of 64 bit drivers.

One way around this is to set up a 32 bit guest OS in a virtual machine and then run your devices from the guest OS, i.e. you can install your printer on a VMWare (or other type) virtual machine with XP or Vista 32 bit (or perhaps a Linux distro) and transfer your files to the guest OS when you want to print them.

Clearly the virtual machine is able to pass on commands to the device either via the host OS, or bypassing it altogether. This seems to me to be a proof of concept for a universal driver translator.

My question is, would a 64 bit emulator program doing essentially the same job as the 32 bit virtual machine be possible? Basically it would be a virtual machine with a stripped down OS that does nothing more than run 32 bit drivers on a 64 bit host.

If it is possible, how come such a program hasn't been written yet?

I'd willingly pay $100 for such software instead of updating my hardware, because running a full blown 32 bit guest OS purely to scan or print things is a bit of a hassle. I'm sure thousands of people would, and the existence of such software would remove one of the major objections people have to getting a 64 bit OS.

posted by Mokusatsu to computers & internet (9 answers total)

This is a very difficult problem to explain to somebody with little programming experience. I'll try, but keep in mind that this is a bit of a simplification.

The issue at hand is not whether or not you can run 64-bit code. It's that the operating system needs to link the driver into the kernel. This means, that after linking the two objects, the computer sees the whole thing as essentially a single program. So, in a homogeneous world, you have a 32-bit kernel and you link in a 32-bit driver, or you have a 64-bit kernel and you link in a 64-bit driver.

That "bitness" refers to how many bits the computer uses to store a number. That is the largest number than can be handled in a single computational cycle natively by the processor. So, if we link 64-bit code to 32-bit code, the processor doesn't know what mode to run in. It doesn't know if the biggest number is 32-bits or 64-bits.

Now, why can't we convert them? Put a little translation layer in that converts between 64-bit and 32-bit representations of the numbers. After all, is the printer driver really using numbers so big that it can't fit them in 32 bits?

The answer is that the numbers aren't just values. They're also pointers. A pointer is a memory address that the program uses to remember where it put a thing. Many of the pointers, as well as the overall layout in memory of code, are determined by the compiler and then simply rearranged and repositioned appropriately when the operating system dynamically links your program together at runtime.

These pointers are absolutely incompatible, and cannot be translated as I suggested above. If you'll take a metaphor of house numbers for street addressing: 32-bit code says, essentially, that all house numbers have no more than 4 digits: 1502, 1201, 94, 7, 9932 are all valid addresses; 31100 is not. 64-bit code says that house numbers are no more than 8 digits: 44329284 is valid, but 44449291900 isn't. The problem comes when the compiler assigns pointers all sorts of nifty stuff (like the checkIfPrinterIsThere() function). If the compiler is 32-bit, it'll make sure to use nothing but 4-digit numbers; the 64-bit compiler is going to do whatever the hell it pleases, up to 8-digit addresses. If my house is a 44933392 Fleet Street, then a 32-bit taxi driver is going to have no fucking clue how to get me there: we can't fit that large a number in four digits, no matter how we try, but nevertheless that's where I live. I have to find a 64-bit taxi driver.

So, while an operating system is frequently capable of running either 32- or 64-bit programs (linux, OS X, and others), they only manage this by having two complete sets of system libraries: one compiled 32, and one compiled 64. Since you can't run a 32-bit kernel at the same time as a 64-bit one, we can't do the same thing with drivers.
posted by Netzapper at 4:24 PM on August 23, 2008 [8 favorites]

Great answer, Netzapper.

See, I'd be willing to spend $100 to "downgrade" to the 32-bit version of Windows, but that's just because I'm not running a renderfarm, or anything that requires 4GB of RAM. Frankly, it just doesn't win out for me, though I could definitely use a bit more RAM. There are too many incompatibilities and issues across the board for negligible performance increases across most use cases.
posted by disillusioned at 7:46 PM on August 23, 2008

Netzapper's answer explains why there isn't a 64 -> 32 bit emulator, but that wasn't the question.

The answer is still probably not, because MS started pushing Vista before most people had converted to XP64, so they dropped those efforts. And that's the same reason no one developed complex general applications for XP64, MS had told them it was an abandoned platform.
posted by StickyCarpet at 8:33 PM on August 23, 2008

WOW64 is the complete set of system libraries netzapper is talking about; it is effectively a translation layer between 32 bit windows calls from 32 bit apps, and the 64 native API. Windows had a similar setup back in the day when we were migrating from 16 bit to 32 bit.

The real answer you're looking for, I'm afraid is that it's not really worth it. The general issue is not 32-bit vs 64-bit; it's new version-itis.

Microsoft requires that all 'vista certified' hardware has 32-bit AND 64-bit drivers. So what's at stake? Old hardware. Hardware that manufacturers have no intention of supporting for new Oses, because they have new shiney products to sell, as you've discovered.

Printers, scanners and network cards have been abandoned galore in the rush to vista, but it's not 64-bit support that's missing generally; it's vista support altogether. To add all the support libraries required beyond those already available, you're going to need much of windows XP or older anyway - you'd be looking at WINE levels of translation layers, and that's been an ongoing project for years, and is still pretty flaky. VMWare works a bit differently, in that it largely acts as application running on the host, and presents a fake hardware layer to the guest. The bulk of the actual driver work for client apps running under emulation is still done by the guest OS.

You couldn't just distribute the significant bits of old windows you need; that would be copyright violation. So you'd need a not-very-trimmed down set of windows files from the owner + licence, plus a trimmed-down vmware layer, all to get old hardware working for people who are unwilling to spend money to upgrade in the first place.
posted by ArkhanJG at 5:17 AM on August 24, 2008

"VMWare works a bit differently, in that it largely acts as application running on the host, and presents a fake hardware layer to the guest. The bulk of the actual driver work for client apps running under emulation is still done by the guest OS."

Indeed.

Sorry about my naive questions, and I am aware of many of the issues Netzapper pointed out already, having been one of those early 64 bit users with XP x64. I've had more than three years of reading explanations about why I can't run perfectly good hardware on my new machine, having to retain old computers just for the purpose of printing stuff, or later on, having to set up virtual machines.

Since my main reason for setting up a 32 bit virtual machine is to allow me to use this hardware, from my point of view a virtual machine is just a heavily overengineered 64 bit driver emulator. No doubt people who live and breath this stuff would object to that statement with an objection beginning with "well, no, technically it is actually a...", but it serves the purpose of making my hardware work on an x64 machine using only software, so clearly it can be done.

So it can be done, but its a bit extreme. It requires at minimum a good 10G of hard disk space to host the guest OS and all the system resources of running two computers at once on the same hardware.

But would it be possible for someone to compile a very simple non-resource intensive OS that does nothing other than read old XP, Mac or Linux drivers (all three would be nice) and run this in a virtual machine app which does basically what VMWare is doing?
posted by Mokusatsu at 6:23 AM on August 24, 2008

But would it be possible for someone to compile a very simple non-resource intensive OS that does nothing other than read old XP, Mac or Linux drivers (all three would be nice) and run this in a virtual machine app which does basically what VMWare is doing?

In short, no. VMWare is not a driver emulator - it's a translation layer for a driver emulator. Your guest OS is doing the driver work, vmware is just pretending to be a CPU, network card, hard-drive and USB hub.

As I say, the WINE project (and spinoffs) has been working on effectively that goal on linux for a number of years, and is still somewhat short of it. Doing it without using the guest OS files directly is very tricky, especially when it comes to microsoft. Don't forget, there's a decade of cruft, written by many, many engineers. Even microsoft struggle to understand and handle all the weird interaction bugs - they've even go so far as to write new code that replicates the known out-of-spec bugs of the old code, so it doesn't break compatibility. And they've got the advantage of the source code, which any reverse engineering team cannot use even if they did have it. Look at the legal hoops and years of effort the Samba team have had to go through just to replicate SMB and CIFS traffic on a LAN!

The only practical way I can see would be to use the original guest files, provided by the user, but trim them down and use only what was needed, with a mini-vm environment. Possible, but so far not undertaken AFAIK due to low return on effort - it's just simpler to use a full emulation environment, and then you're not limited to a single task.

Interestingly though, windows 7 is supposedly going to break binary compatibility with older versions altogether, and have a more advanced VM-like environment with a compatibility layer for old apps; similar to what happened with cocoa/carbon on OSX I believe. Whether they'll go so far as to emulate an binary API for kernel drivers though, I suspect probably not.
posted by ArkhanJG at 6:55 AM on August 24, 2008

This is possible, but it's not a great business proposition.
This would be expensive to develop and test as a commercial product, given the fact that a large sampling of third party drivers and hardware are intrinsically part of the testing matrix in this case, so the process would not be trivial.
The market for it seems quite small, and would shrink over time as 64 bit drivers become more common and old hardware is retired. Bear in mind that consumer-level computer peripherals are pretty cheap these days, particularly printers.
posted by w0mbat at 12:32 PM on August 24, 2008

But would it be possible for someone to compile a very simple non-resource intensive OS that does nothing other than read old XP, Mac or Linux drivers (all three would be nice) and run this in a virtual machine app which does basically what VMWare is doing?

Fine, assume this is written. Now tell me how the guest OS's usb hub will talk to the host OS. This is the equivalant of plugging an A to A cable into one computer and another and expect to be able to browse the shares.

Somewher in here you are missing the part where the guest OS needs to emulate the device to the host OS to make it transparent. This is a big problem without the driver source. This problem is not the same as "If I can run a virtual OS then I can transparently emulate 32 bit devices." Its two very, very diffrent problems.
posted by damn dirty ape at 12:44 PM on August 24, 2008

One virtual OS you might care to try running, if all you're going to do with it is enable the use of older devices, is Windows 98SE. There are several really stripped-down versions available. They won't take up anywhere near 10GB of your hard disk, and will run quite happily in a VM with 96MB RAM.

You may well find, though, that if your scanner or printer isn't quite old enough, that getting Win9x drivers for it is as difficult as getting 64-bit ones :-)
posted by flabdablet at 12:29 AM on December 21, 2008