Hacker News Reader

Comment by acallan | Hacker News Reader

Why was 64-bit Firefox for Windows so late to release?

Chrome also took a long time to release 64-bit builds to Windows users. They weren't available on the stable channel until Chrome 37 was released in August 2014:

http://arstechnica.com/information-technology/2014/08/chrome...

Compared to Chrome, Firefox had more problems with legacy add-on compatibility, because in addition to 32-bit NPAPI plugins it also has to deal with legacy binary extensions that link to Firefox's internal libraries.

(For further comparison, Microsoft released 64-bit builds of IE8 in 2008, but few people used them at first because there were no 64-bit versions of popular plugins like Flash until years later. Browsers on Mac OS X worked around this by shipping fat binaries that could launch in 32-bit mode when 32-bit plugin compatibility was necessary.)

Actually, IE has had 32-bit and 64-bit version since the beginning of 64-bit Windows, originally as separate items on the start menu.

Yep, I used it a few times on 64-bit XP in 2003ish.

Windows is indeed the last (64-bit on Linux and Mac has been there for a long time). I think the main issue was binary plugins, which are more common on Windows, and can be incompatible with a 64-bit browser.

I don't know why the release was so late, but I'd speculate that it took a while to find enough compelling reasons to go from 32 to 64 bits on Windows. Having run Waterfox, the third-party 64-bit build for Windows, for some time along with the 64-bit version of IE, I haven't seen any real difference in performance relative to the 32-bit versions of those browsers.

Websites like https://clara.io and https://www.onshape.com/ really appreciate having a 64 bit browser. Loading a large model on a 32-bit browser often results in random crashes.

The performance difference is substantial. Seems to be mostly due to memory usage patterns. With more than a few tabs open, the 32-bit version pauses annoyingly every few seconds. The 64-bit build does a lot better.

And they still hasn't properly fixed the JS JIT to comply with Windows x64 ABI including SEH! Interestingly, MS has promised to release their own JS JIT used in Edge and IE as open source.

Is there a compelling reason for a browser JIT to comply with platform ABI? Third party binaries are not going to be linked in or called from the JIT-ted code anyway.

Proper SEH support.

But why? Only sandboxed, JIT-ted js code is going to use this custom ABI. What exceptions do you expect to handle?

All exceptions including CPU exceptions like divide by zero or access violation uses SEH on Windows.

…which you shouldn't be getting in jitcode.

IIRC, in-process plug-ins from third parties that do not have a 64-bit version made using a 64-bit build unattractive for many.

If so, they either deem the impact of not supporting various plug-ins lower, or they run them out of process now, so that plug-ins that need it can run in a 32-bit process.

I was wondering the same thing; I had to check on wikipedia that indeed consumer-grade 64 bit processors were on the market in 2003 (AMD Athlon 64). I also remember Windows XP and Mandriva had support for 64 bit processors at the time. This launch doesn't feel like the celebration it should be.

On the other hand, 64-bit XP wasn't really ready for prime time. Back in that era, I built up a system and was originally intending to run XP64 on it - until I read about its poor compatibility with the 32-bit world (especially drivers). I wound up returning the unopened XP64 and got 32-bit instead, which turned out to be the right call.

In retrospect, adding PAE support to XP SP2 would probably be less risky (though would still require new drivers).

Reply on news.ycombinator.com