Windows 7 Survival Guide: From 32- To 64-BitWindows 7 Survival Guide: From 32- To 64-Bit
Your old hardware isn't doomed. Here's how to migrate 32-bit printers and scanners onto your 64-bit version of the Windows 7 operating system.
A list of attached USB devices available to programs running in 32-bit XP Mode. |
---|
Windows as a whole -- Windows XP, Vista, Windows 7 and the operating system's server editions -- has been shipping in both 32- and 64-bit editions for some time now. That's more than long enough for hardware manufacturers to get on the ball and supply 32/64-bit device drivers for everything they sell.
In fact, most every printer, scanner, video camera, or other hardware device you can buy today comes with drivers for both platforms in the box.
[Find out when Windows 7 will be right for your Enterprise. If you're weighing whether or not to migrate to Microsoft's new operating system, then be sure to check out information's Virtual Event: Business Case For Windows 7. Click the link to register and immediately access an on-demand replay.]
That's great if you're buying a whole new system. But what if you're migrating over a printer, scanner, or webcam -- individual peripheral devices from an age just slightly before the 64-bit years?
That's where things get more difficult.
While 32-bit applications generally run without issues on 64-bit Windows, 32-bit device drivers aren't as lucky. There is so far no mechanism in Windows to take a 32-bit device driver, wrap it in an emulation layer, and use it in Win64. This means that a great deal of hardware, otherwise perfectly useful and totally functional, is doomed to be useless to a whole swath of existing Windows users.
There's no reason to take this situation lying down, though. Depending on your budget, circumstances, and needs, you can go a long way -- sometimes all the way -- toward getting unsupported hardware working again in 64-bit Windows.
Scanners and printers comprise two of the largest classes of devices that have been unfairly marginalized because of the 64-bit switchover. To that end, we'll be looking at both of these (with some occasional digressions) and exploring ways to make them operable.
Why 64-bit, Anyway?
Why use 64-bit Windows in the first place? Desktop machines that ship with more than 3GB of RAM also come with 64-bit Windows installed by default. It's the best possible way to make use of all that memory efficiently.
Individual 32-bit apps may only be able to use so much of that memory at once, but those of us who run a lot of apps side-by-side get a boost from it. Also, applications that perform certain kinds of processing -- encryption, for instance -- run markedly faster as 64-bit binaries.
Not every computing device is bound to go 64-bit. Netbooks, for instance, or low-end PCs that top out at 2-3GB RAM don't bother going 64. But at this point it's safe to say that most any desktop computer (and notebook) from the midrange on up will be 64-bit. As a result, the number of users who encounter legacy device incompatibilities will increase.
At least for the time being. Wait long enough and all of the incompatible hardware ought to fall out of use and be replaced with newer devices. But that's no strategy for those of us who have hardware to be used now.
A printer with no 64-bit drivers, installed and running under 32-bit XP Mode. |
---|
XP Virtualization: Does It Help?
When Windows 7 was near release, one of the planned features that turned heads was native 32-bit Windows XP support. Microsoft accomplished this by placing an entire, fully licensed copy of XP running in a virtual machine. This way, any program that absolutely had to run in XP could be installed there and would run at near-native speeds.
The big downside with such an approach is that it requires the program to run in what amounts to a self-contained window with little interaction with the host machine. Fortunately, Microsoft came up with an elegant extension to this behavior: "seamless mode." Applications installed in the VM can be run directly on your desktop, and work almost exactly like their real-computer counterparts.
The thing about XP Mode is that it's geared more for emulating applications, rather than supporting devices. You can still run 32-bit device drivers through XP Mode, but there's no direct interface to the device -- you have to use an application of some kind. For a scanner, you'd use a program to acquire an image from the scanner; for a printer, you'd need a program to perform a print action.
Fortunately, once you have an application you can use to talk to the device, this whole process becomes much easier to deal with. Right-click on the emulation application's icon in the Taskbar and you'll see a menu choice named Manage USB Devices. From there you can attack whichever USB devices are used by the program in question and make use of them through the emulated program.
Note that there are still a few behaviors that won't work. Example: You can't drag and drop files to the integrated app, but you can browse the host machine, which will show up as an attached network drive.
Printers
Printers are something of a best/worst case scenario, in that you might be able to work around the problem right away -- or be stuck with having to jump through any number of hoops.
If the printer in question understands generic PostScript or HP's PCL, chances are very good you can simply install a generic 64-bit driver that speaks to those protocols. HP, in fact, offers just such a thing.
VueScan works with just about every scanner known to man. |
---|
The bad news is that advanced, printer-specific features (e.g., an advanced stapling/collating system) won't be available with a generic driver, but getting back a basic level of functionality is often worth the tradeoff.
The worst case is when you encounter a printer that uses a proprietary wire protocol and doesn't speak PostScript or PCL. Inkjet printers are infamous for this sort of thing, but some laser printers also suffer from it. Case in point: my own HP LaserJet 1000, which uses the proprietary Zenographics protocol, does not speak PCL, and has no 64-bit drivers whatsoever. If I wanted it to work, I had to hack a solution together, or simply install the printer on a 32-bit instance of Windows and open any documents to be printed there.
Another workaround: I set up a print-to-.PDF driver on my 64-bit machines, and had the results printed by default into a shared directory that the 32-bit machine would poll periodically for new documents. Yet another solution involves simply printing to .PDF on the local machine, and then invoking an XP Mode instance of Acrobat Reader to print it to the actual device.
All workable, but horribly convoluted. My long-term plans now involve buying a printer that speaks at least PCL6, and never touching anything with a proprietary wire protocol again.
Scanners
Scanners are another class of hardware that seem to be hit particularly hard by the 32/64-bit changeover. Like printers, they tend to remain in use for a long time. I've seen scanners five and ten years old still delivering acceptable results, with the only incentive to replace them coming in the form of a newer OS that doesn't have proper driver support.
Many scanners not more than four years old have no 64-bit support and probably never will, because all official manufacturer support for those devices has been discontinued.
Leave it to an entrepreneur to step in where others have walked out. Programmer and former NASA/JPL staffer Ed Hamrick felt he could put new life back into old canners that had no reason to end up in a recycle bin, his own included.
To that end he wrote VueScan, a program for both 32- and 64-bit Windows that works with a staggering variety of scanners. It doesn't depend on the manufacturer's drivers to do this; instead, Ed wrote his own generic device driver, and constantly adds support for new scanners as he goes along.
IrfanView running in XP Mode, sans desktop integration. |
---|
The program has a few limitations. My biggest gripe: it doesn't yet perform descreening/moiré removal on acquired images, which means scanning printed material (e.g., archiving magazine clippings) won't give you the same quality results as, say, scanning an actual photo. It's also not a free program -- the trial version is fully functional, but watermarks any saved images. Still, for $40, it's cheaper than buying a new scanner.
Another solution is to use the same virtualization approach as described above for printers. If you still have another 32-bit Windows machine in the immediate vicinity, you can attach the scanner to that, use Remote Desktop or VLC to access the system, and save the results on a shared drive somewhere. Not perfect, but it does work.
I pulled a trick similar to this for several months, using 64-bit Vista on my main system and 32-bit XP on another machine. Later, after installing Windows 7, I was able to use XP Mode to run the application I used to talk to my scanner, IrfanView . It worked decently well in regular XP mode, but worked best when I set it up as an application to run in seamless mode directly on my Windows 7 desktop.
A third possibility is to use a Linux machine -- a standalone box, or a virtual machine -- with the scanner plugged into it, and access that remotely. Scanner support in Linux is fairly robust thanks to the SANE project; most any scanner you have on hand should work as-is.
And as with printers, both 32- and 64-bit editions of Linux support the same scanner hardware. I used VirtualBox for this trick, which can supply input from a USB device through a mechanism similar to the one used by Virtual PC for XP Mode.
The biggest limitation there is the results returned by the SANE driver: while it's broadly configurable, the interface is a bit of a mess. Also, if you use VirtualBox, note that it does not track the state of USB devices as accurately as XP Mode. Devices that are plugged in or unplugged while VM sessions are in progress may not show up, or may need to be reinitialized while the VM is turned off.
When it comes to 32- vs. 64-bit, we're in a transitional phase. It's something like the 16- to 32-bit transition that took place when Windows 95 gradually eclipsed Windows 3.1. Windows 95 was a hybrid of 16- and 32-bit technologies to allow the existing 16-bit world to migrate as gracefully as possible. But the differences between the 32- and 64-bit worlds are a good deal more profound.
The brunt of the changeover is being borne by users of legacy hardware; their choices amount to making do or ditching what they have. Until all that legacy hardware is out of service -- which may not be for a good long time to come -- the 32/64-bit divide will need to be spanned with ever-increasing creativity.
Virtual Event: Business Case For Windows 7 -- Join Microsoft's top Windows executives and information's editors for a live, interactive Webcast that will dive into how enterprises large and small are evaluating the benefits -- and weighing the challenges -- of migrating to the new platform. Find out more and register.
For Further Reading
How To Upgrade To Windows 7 From Windows XP
Microsoft Windows 7 Under The Hood
About the Author
You May Also Like