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!