64-bit Firefox discontinued on Windows | Hacker News Reader

64-bit Firefox discontinued on Windows

groups.google.com

50 pointsmappu75 comments

As mentioned in the bug and other locations, Firefox's x64 builds are pre-release nightlies only and not anywhere near ready for primetime. They still get a lot of bug reports that are x64 only and don't have resources dedicated to it because Firefox OS and Metro mode have higher priorities.

For folks in the bug saying that this will make them somehow abandon Firefox, if 64-bit is really that important to them, they'll have to use Internet Explorer only and deal with many popular plugins not working (Adobe Reader, Quicktime, etc).

Opera has an experimental Win64 build from February that is now out of date with known security issues. No further progress has been made or release schedule announced.

Chrome, Chromium and Iron are 32-bit only and have no 64-bit builds, not even pre-alpha experimental ones.

Apple has abandoned Safari for Windows entirely.

So, as far as 64-bit browsers on Windows... you've got IE and that's it.

UPDATE: As correctly pointed out below, there is a snapshot (alpha, incomplete, unstable) build of current Opera for Win x64. Apologies on the incomplete information in this post originally.

Plugins not working is a security / reliability bonus, from my perspective; every few months, I have to hunt them down and delete / disable them. At least it's easier to disable them in Firefox than in Chrome.

  chrome://plugins

Your information about Opera is incorrect. The current release (12.11) has a x64 build (http://snapshot.opera.com/12.11-1661_windows.html).

Why the downvote? The link takes you to the download for the 64-bit Windows version that was just released

I stand corrected, I was basing it on the out of process plugins page that they used to keep updated: http://dev.opera.com/articles/view/64-bit-opera-and-out-of-p...

Opera does have a Snapshot Win x64 build available which they describe as "Cutting edge, alpha quality, incomplete, and often contain critical bugs". This does sound a lot like the now-discontinued Firefox Win x64 nightlies (aka nowhere near stable).

(PS - You get an upvote from me. Not sure why someone downvoted you.)

Download button on main page of www.opera.com provides x64 version for me if I use browser with Win64 and x64 in user agent

http://www.opera.com/download/get.pl?id=35259&thanks=tru...

It is not experimental.

http://www.opera.com/docs/changelogs/windows/1200/ — Changelog for 12.00 release includes official 64-bit support.

Page now updated. :)

"As correctly pointed out below, there is a snapshot (alpha, incomplete, unstable) build of current Opera for Win x64." (c) JohnTHaller "Update, November 22nd 2012: Please note that Opera 12.00 final shipped with 64-bit and OOPP support, and that as of version 12.02, OOPP is disabled for Windows 32-bit." (c) Opera.com You are wrong :P

Fact is, sometimes people downvote you simply because they don't like what you have to say, not because it is wrong or even questionable.

[deleted]

AFAIK IE10 can automatically select 32-bit or 64-bit processes as needed: http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/under...

It doesn't actually work properly from our preliminary testing which causes us a number of problems thanks to some legacy ActiveX crap we've been trying to kill for years.

Both Chrome and Chromium have x86_64 builds for Linux, do you know what it is about windows that makes it so hard to ship a 64 bit build?

Firefox also has x86_64 builds for Linux, and OS X too.

I don't know why 64-bit Windows is a particularly difficult combination for apparently all browsers (but IE).

I have to assume it is probably a problem for IE too, but MS is the only browser vender really in a position not to be particularly bothered by whatever it is that could be causing that trouble. I too have no idea what that trouble could be though.

Well, Microsoft does have only a single target platform, unlike most other browsers, perhaps that's the main issue. Microsoft also only targets recent Windows versions with new IE releases, also unlike most other browsers.

I don't think it's necessarily that it's more difficult but that there is less demand. On linux distros (especially since most stuff is open source) they try to get everything be 64 bit on 64 bit installs, some distros don't even ship 32 bit system libraries by default. That's why linux users wanted 64 bit flash so much(you need 64 bit plugins for a 64 bit browser although there was a hack called nspluginwrapper to let you use 32 bit flash in 64 bit fiefox). I'm guessing there is a somewhat similar push on OS X to get all 64 bit software on a 64 bit os.

On windows, firefox is just a single installed program(unlike linux where firefox's library might be shared with thunderbird, etc.), and a number of apps are 32 bit, and thats fine. Plus there is a larger selection of plugins many of which may never get a 64 bit version.

Also I may be wrong but I think that browsers these days have a lot of per architecture optimizations targeting x86 and separately arm(x86-64 optimization being a lower priority), so that 64 bit browsers may actually be slower.

X86 and x86-64 are pretty much the same, so any byte-code optimisation will be the same for either. X86 extensions, like SSE, are also another major area of optimisation, with modern cpus obviously having more extensions.

This isn't quite true; x86_64 has more general registers, which are helpful in writing VMs. At one time, Apple JavascriptCore was 60% faster on x86_64 Safari than on x86 Safari on the same machine, though I think the gap has reduced.

Chrome can get away with being 32-bit-only because it uses multiple processes for rendering, which means that it can make use of many times more RAM than a single 32-bit process ever could. It'll quite happily use 64 gigabytes of RAM or more if you have enough tabs open. Firefox can't do this.

Following a curiously short discussion, and despite 50% of Nightly testers on windows using the 64-bit builds[1] and a Windows user demonstrating firefox using 10GB of memory[2] (above the address space limit of 32-bit), the 64-bit nightly builds of Firefox on Windows are to be discontinued.

_______________________________

1. https://bugzilla.mozilla.org/show_bug.cgi?id=814009

2. http://archive.installgentoo.net/g/thread/29261499

3. https://groups.google.com/forum/#!topic/mozilla.dev.apps.fir... - Full discussion thread

Heh, that comment thread pretty much sums it up. Shame to see this happen.

Misleading headline and obviously you know it.

Seems like it would be better to focus on the single problem of not crossing the 32-bit address boundary rather than the multitude of x64 problems.

That's not really possible -- you'll see that the folk crossing that boundary are keeping open several hundreds of tabs at a time.

As memory usage is reduced, these folk will just open more tabs.

In case it's not obvious: [2] links to a chan style discussion board, with chan style culture. The first thing I read (because it's in big red letters) was "I WANT TO REMIND YOU THAT CP IS NOT TOLERATED AND MUST BE REPORTED".

Sorry, possibly could have made that more clear (it's also not affiliated with Gentoo). In defense of 4chan, the exact same rule applies to HN (the law applies to everyone), every large website has trouble with spam, and there's nothing offensive there outside of mild profanity and teenagerism.

It's otherwise a perfectly ordinary technical discussion thread from a board that has a large number of firefox users and where Nightly is strongly encouraged amongst PC enthusiasts.

Yes, I agree. I was perhaps a bit sniffy. Often great discussion can be found on those style boards.

This decision makes no sense.

I figure that, sometime in the next 10 years, 32-bit OS'es will go the way of 16-bit OS'es. The time to iron out the bugs in the 64-bit version is now, while it's only used by diehard techies who understand the necessity of switching to 64-bit.

If we wait until the unwashed masses are forced to switch by ever-advancing technology, they'll jump ship for browsers that have been preparing for years.

Also, the fact that the link has exactly one post in between the proposal and the switch tells me that nobody noticed it, and more effort should have been made to get community review, buy-in, sign-offs. There should have been lots of commentary and input on such a fundamental feature as 64-bit support in such a high-profile open-source project.

Agreed.

To be fair, there was some small amount more commentary. See the other post for more links - the submission points simply to the announcement thread.

The real discussion is here (~40 messages): https://groups.google.com/forum/#!topic/mozilla.dev.apps.fir...

The poster asked that people follow up in a different newsgroup.

To be fair, as others have mentioned Chrome doesn't even have a pre-Alpha 64-bit version, and a number of plugins don't work with 64-bit browsers. Sometimes you have to pick your battles, it's not like Mozilla has infinite resources.

I'm one of the leads for the 64-bit Chrome on Windows work, and it is very much underway. I can't commit to a timeline, but we are attacking this pretty aggressively right now because it's a nice win on both the security and performance fronts. I'm a bit shocked to see Firefox moving in the opposite direction.

Are the 64-bit challenges on Windows much different than OS X or Linux? Chrome for OS X is also 32-bit, but Firefox is 64-bit.

Some differences include the need for JITs to generate proper unwind tables for SEH to work properly.

As well as a different calling convention.

Well, OS X is easier because much of the work has already been done for Linux 64, as both are posix-ish lp64 architectures. Whereas Windows is llp64 plus its own APIs and ABIs, which means much more unique porting issues.

Beyond that, there's all the infrastructure you need to stand up for development, continuous integration, QA, metrics, and shipping to hundreds of millions of users. The logistics of that part are almost the same as supporting an entirely new OS, and in the case of Windows it's one with an insanely large and diverse population. So yeah, that parts actually a lot worse just because of the sheer numbers.

To be honest, Chrome is multi-process while Firefox is single-process.

To elaborate, each tab in Chrome can use up to 2GB as it runs in its own process, while the entire Firefox window is limited in a 32-bit architecture.

So the need in Chrome to go 64- from 32-bit from a memory perspective is less.

The reason seems to be that they are focusing on uninteresting crap like Metro and FirefoxOS.

If there are not 64-bit browsers, how will there ever be plugins to work with them?

I don't think plugins are as compelling an argument today as they were a few years back. Flash is basically gone, and Firefox's PDF viewer is 100% Javascript.

The only plugin i have is the JRE - which has provided a 64-bit version for over 10 years (SPARC64 in Java 1.4). And i can't remember the last time i chanced upon a Java applet in a webpage.

Even the Unity3D Web Player has a 64-bit browser plugin. I can't imagine what's really missing other than outdated versions of RealPlayer.

Flash is still installed on over 99% of desktop browsers. And the pdf viewer is way too slow (at least for me) for real world usage.

> I figure that, sometime in the next 10 years, 32-bit OS'es will go the way of 16-bit OS'es.

Yep. I'd prefer in Firefox (and others) abandoned 32-bit windows instead.

Windows Server 2012 does not have a 32-bit version, it's 64 bit only.

Related, why is there a 32 bit build of Windows 8? Does some of the target hardware at the low end of the market need it? I guess the server space has has a higher threshold of minimum hardware than tablets.

The headline is completely wrong and somehow links to something that isn't the actual discussion, which is here: https://groups.google.com/forum/#!topic/mozilla.dev.apps.fir...

Here's further explanation from the opening poster of that thread:

For the purposes of this thread, it is already a done decision that we aren't going to ship 64-bit Windows Firefox builds in the first half of 2013, and probably not at all in 2013. In the meantime, we aren't going to fix crashes or plugin bugs that only affect 64-bit builds. Those decisions have already been made. The only question to decide here is whether the existing 64-bit Windows nightlies provide any value to the project.

They're not discontinuing 64-bit Firefox on Windows; they haven't even released it yet. They do intend to release it, but probably not until 2014.

It's been mentioned already - the submission links just to the announcement. I understand and sympathise with all the technical reasons behind the decision. But i still consider it a serious regression on Mozilla's behalf, and it's a major disruption for every single user who used this configuration.

I'm happy for a moderator to change the post title if it's too inflammatory, "Discontinued" was perhaps too strong a word. How about "64-bit Firefox no longer available for Windows"?

I think it's a stretch to say that they do intend to release a win64 version. I think that, while they may not have ruled out ever doing such a thing, it's pretty clear that since they are not working on 64-bit bugs they have no plans to get any win64 builds ready for release.

Terrible decisionmaking on Mozilla's part. Can you even buy a 32-bit Windows PC anymore?

Those developers who are asserting that there are no advantages to a 64-bit executable besides RAM addressability are simply wrong. Any nontrivial MSVC C/C++ application will gain about 5-10% performance when recompiled to target x64. Why, I don't know, but that's what happens in my experience. It could be that having eight additional 64-bit registers available to the compiler overcomes the L1$ penalty associated with larger pointers.

Point being, 64-bit executables are the current best practice in Windows programming, beyond any possible debate. This is just yet another move up the shark-fin curve on Mozilla's part.

It seems that the only people who need 64 bit browsers are those who have very many tabs open.

I don't understand that use case. I don't understand how someone can work with 500 tabs open. Why do you run a browser with very many tabs open?

Or do you need 64 bit for some other reason?

EDIT for the silent downvoters: I'm not criticising people who have very many tabs open. Nor am I saying that's the only reason to have 64 bit browser.

Some people (like me) have stopped using bookmarks and simply leave open interesting pages.

I have ~20 browser windows open, each window is a virtual workplace. One is political news, one is tech news (featuring hacker news, the Register, slashdot, appleinsider...) one is Java SE API tabs, one is Clojure, one is imageboards.

While 500 tabs is a bit much, I can easily get to 200 without getting lost. It is simply a way to organize my stuff. Had one window with several tabs open for Scala, then found that Scala is not for me. Closed that window and it is all gone. No need to fiddle with bookmarks.

That said, the missing 64bit support will surely not make me leave Firefox. After all, it will surely come back over time.

You might like a tree-tabs plugin of some sort. Makes the tab bar run vertically along one size and tabs open into a collapsible tree structure; I find it very nice for handling hundreds of tabs.

On Chrome we don't need it for large numbers of tabs (because our multi-process architecture covers that). However, we're working on it because we've identified significant security benefits (e.g. much better ASLR) and improved performance in a number of scenarios (mostly due to the additional registers).

If I have the ram.. why not use it? Putty and Outlook can sop up the remains, but the bulk of my memory is either going to be used for my browser.. or wasted. High numbers of tabs certainly isn't a usage pattern that is for everybody.. but clearly there are many of us who use it.

Could someone enlighten me why 64 bit seems to be so hard to do on Windows as compared to other platforms?

It's not, at least on MSVC, unless you have a lot of inline asm in your C/C++ codebase. You change a couple of -D flags on the compiler and linker command lines and build with the 64-bit compiler. A few Win32 calls and data types will need to be changed. If you're in the habit of casting pointers to ints or vice versa, you'll need to change those ints to size_t or equivalent types, as you should have been doing all along.

Few/no Windows developers should be treating their 32-bit builds as their primary target at this point, unless (as in Mozilla's case) they need to interface with a lot of legacy 32-bit plugins. The correct course of action for Mozilla would be to pressure the plugin developers, though, rather than to put the horse in front of the cart as they're doing.

They could have made the same call in the Windows 95 days, when 16-bit code was still viable. It would have been silly then, and it's silly now.

That does not seem to explain why 64 bit is apparently more problematic on Windows than on other platforms. Could you elaborate on that?

Sorry, I have no idea where they're coming from when they say that. It's got to come down to plugin compatibility.

In fact -- again, for MSVC projects -- debugging a 32-bit application on a 64-bit PC is what's painful. There are serious bugs in Visual Studio's WoW64 support that have remained unfixed for years.

>rather than to put the horse in front of the cart as they're doing As a non-native speaker, I am confused. Over here, we put the horse in front of the cart back when we still used carts and horses. Makes more sense to me.

The expression is "to put the cart before the horse", i.e. do things in the wrong order.

As a non-native speaker, I am confused

No, you got it right. Cliché fail. :)

There is always waterfox for 64bit http://www.waterfoxproject.org/

I used Waterfox for about 6months. It was perfect, until I found out that 32bit Firefox is faster in the benchmarks.

64bit applications are not always better. It actually can waste resources in some applications. My IM and Text editor are 32bit and there is no reason for them to be 64bit.

I agree, if you're not touching the memory limits of 32bit, there is no reason to do 64bit. Because 64bit applications have to pass 64bit addresses to read from memory it is slower than 32bit which only have to pass 32bits of data (simplified but true).

This is going to sound crazy, but I was running 64bit nightly (on windows 8) and didnt have a single problem until I read this article... Immediately after following some of the links to the discussions on google groups, firefox crashed twice, and then also prompted me to update again...

Anyone know how to tell if if the version of firefox has been force-updated to 32bit (the about dialog does not seem to indicate which platform I am using).

Also, I don't have any plugins installed. The only plugin I used before I upgraded to windows 8 was flash, and now that HTML5 video is pretty main-stream, and WebGL is on its way, I don't see myself ever installing flash plugin again...

You can type about:buildconfig in you address bar to see info about a particular Firefox build.

I was really looking forward to the 64-bit version but it never looked as if Mozilla was ever serious about it.

What did you need that only x64 could provide?

My desktop has 24GB of RAM, yet Firefox crashes on a regular basis when it bounces off its 2GB limit, usually when many image-heavy pages are opened, especially simultaneously from a folder of bookmarks. Seems like the single simplest thing to fix this is the option of using a 64-bit binary, given that it appears most of the work is already done.

The alternative is to break up the browser into multiple processes, much like Chrome. That would however reduce the distinctiveness of Firefox and be one less reason to keep using it. Though the reliability effects of using multiple processes is probably better in the end.

But sooner or later - sooner if various GL things ever get proper uptake - individual web pages are going to need more than 2GB to display and run. The bullet will need to be bitten, even in a multi-process model.

2GB limit? Unless something went wrong on your system firefox should be marked as large address aware and get 4GB.

I'm impressed that you've gotten a browser that big on normal pages. I've only gotten it on ridiculously huge test pages or from memory leaking over time.

I run into the 2G limit very frequently too. I usually shutdown my home & work systems only once a week. Firefox too runs continuously from the 1st day of the week.

Over the duration of a week, as I open more webpages, the virtual memory consumption rises continuously till it hits the 2G limit and then the process kills itself. Usually during the last few hundred MB before the 2G limit, it becomes pretty unresponsive.

I believe you're referring to the linker options for large memory awareness http://msdn.microsoft.com/en-us/library/wz223b1z%28v=vs.80%2...

I'd be glad if as a user (not developer) I can set that option somewhere.

P.S., I am a developer, but over time, you learn that building unfamiliar codebases is not a trivial exercise. On Win32, I'm just happier downloading vendor provided binaries. On Linux, I can be both, happy and frustrated, building my own binaries with Gentoo.

Firefox.exe is indeed large address aware (I just checked), but I had never seen it use more than 2GB of address space. It usually hovers around 700M of private memory and 1.5G of address space.

However, I just opened a few image-intensive pages and monitored the process, and got address space up to 2.4G or so. It's been a while (perhaps 6 weeks) since I saw a crash, maybe it's been fixed recently.

What was the advantage you saw in it?

From the brief discussion, it sounds like it had inferior performance to the 32 bit builds, and was buggier to boot.

Yeah, that was the problem. Downloading from the servers, I tended to choose the x64 version and it was never good. The x86 always have been better.

http://www.chromium.org/developers/design-documents/64-bit-s...

Reply on news.ycombinator.com