Log in

No account? Create an account
Previous Entry Share Next Entry
64-bit applications
Frogmarch 2002 - Whitby
There has been furore this week after Mozilla removed the 64-bit version of Firefox for Windows from their nightly builds. They said that the 64-bit version for Windows wasn’t a priority for their development team, and that compatibility and performance problems meant that the 32-bit version of Firefox worked better for users. This is despite their Mac OS X of Firefox being a “universal” application, containing both 32-bit and 64-bit code, and apparently not suffering from compatibility or performance problems. (I understand that their Linux versions of Firefox are also 64-bit.)

There have been strong views expressed about this in some parts of the technology media, although I suppose one should take a step back and accept that Mozilla can and should make their own decisions about the priorities of the Firefox developers.


On my Mac, the majority of applications are “universal”, and run as 64-bit applications. Apple has made the move to 64-bit reasonably painless, and I would imagine that most users are unaware that the architecture of their applications has changed as the operating system and applications have been updated.

Microsoft, however, seems to have made more of a song and dance over 64-bit, with separate installations of Windows for 32-bit and 64-bit architectures, and different versions of applications available. I wonder why they didn’t go for a universal approach? It seems to have made life unnecessarily awkward for their developers.

  • 1
I've been x64 at work for so long now that I can't remember when it was exactly (but it was XP when I switched). At home I've been x64 since the new machine I got around Windows Vista launch time.

.NET programs are sort of equivalent to Mac "universal" programs, in that for the most part you compile them once (to IL) and at runtime they'll be x86 or x64 depending on where you run them. Exceptions to this are when they do "interop" (directly calling the Windows API, rather than a .NET equivalent), in which case they'll be bound to the bittedness they were compiled for.

While I think .NET programs are a bit more widespread than people sometimes think, the take-up is not overwhelming, and I guess that's for two main reasons - pre-existing apps it wouldn't be economic to rewrite, and concern about performance if you're not coding to the metal.

There's another catch though, which is that MSI installers are not universal. So even if your .NET app is bit-agnostic, the installer you use to put it on the machine isn't. No doubt it's possible to do something about this with clever bootstrapping, but with installers often left as an afterthought, most won't bother and will just have two installers, even if what they're installing is identical.

As for Firefox's decision, in Windows 7 both versions of IE existed, but the x64 version was not much used and had distinctly less support in the form of add-ins. Perhaps Firefox is in a similar place. I'm not quite sure what the story is on Windows 8 x64, but a little bit of checking with Process Explorer just now suggests that the desktop version of IE is still x86, but the more locked down Windows Store version is x64. There may also be an x64 version for the desktop, but if so it's well hidden and unlikely to be launched by someone who hasn't gone hunting for it.

  • 1