How to make stubborn 32-bit apps work on 64-bit Windows

Darien Graham-Smith August 6, 2009

By now you’ve hopefully seen my feature on 64-bit Windows in the latest issue of PC Pro. And perhaps you derived some comfort from my breezy assurances that “you don’t need to worry too much about application compatibility. Almost all modern 32-bit software should install and run flawlessly on a 64-bit edition of Windows.”

How to make stubborn 32-bit apps work on 64-bit Windows

Well, of course, whenever you write something like that you’re asking for trouble.

Sure enough, just as our September issue was landing on the newsstands, I was discovering that PC Pro’s internal CMS client only worked on – you guessed it – 32-bit Windows. Trying to create a new review from my 64-bit desktop yielded only an obscure error about a missing COM class factory.

Flying the flags

A little digging unearthed the problem. Some naughty developer had written a perfectly valid 32-bit .NET application, but had neglected to flag it as specifically 32-bit code. 64-bit Windows was therefore running it in 64-bit mode, causing errors when the software couldn’t access the 32-bit system resources it expected.

Luckily, this is an easy problem to fix. Microsoft’s CorFlags command line tool – part of the .NET Framework – lets you modify the header flags on executable files, including the one that specifies when an application needs to be run in 32-bit mode. Setting this flag for our database application was a simple matter of typing CorFlags application.exe /32bit+

And voilà – one 32-bit application running perfectly on 64-bit Windows. Worth a try if you ever run into a similar problem.

Which Program Files folder?

While I’m on the subject, here’s a related problem we ran into back when we started to review PCs running 64-bit Vista. In this case the troublesome software was none other than the PC Pro real-world benchmark suite. Everything appeared to install perfectly, but when we actually launched the tests we received “resource not found” errors.

I set about tracing the problem with the help of SysInternals’ indispensible Process Monitor utility, and once again, the explanation turned out to be mercifully simple (so simple, in fact, that I felt a bit foolish for not having worked it out myself).

Various files weren’t being found because on 64-bit Windows the “Program Files” folder is reserved for 64-bit applications only. 32-bit programs install into a folder named “Program Files (x86)”. Our test scripts included hard-coded paths that were failing because our 32-bit applications weren’t in their usual location.

If you come across a problem like this, you can easily fix it by removing explicit references to “C:\Program Files\” and using %ProgramFiles% instead (this clever environment variable should resolve to either “Program Files” or “Program Files (x86)” depending on whether the process calling it is 64-bit or 32-bit). If you can’t get at the source to change the paths, a quick and dirty workaround is to manually copy your 32-bit files into “Program Files”. Once I’d done this, our benchmarks ran without a hitch.

So there you have it: 32-bit applications do run on 64-bit Windows… but sometimes you need to work around a few programmer assumptions to get them going!