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.
Why the downvote? The link takes you to the download for the 64-bit Windows version that was just released
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.)
It is not experimental.
I don't know why 64-bit Windows is a particularly difficult combination for apparently all browsers (but IE).
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.
3. https://groups.google.com/forum/#!topic/mozilla.dev.apps.fir... - Full discussion thread
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.
As memory usage is reduced, these folk will just open more tabs.
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.
The poster asked that people follow up in a different newsgroup.
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.
So the need in Chrome to go 64- from 32-bit from a memory perspective is less.
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.
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.
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.
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.
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"?
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.
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.
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.
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.
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.
No, you got it right. Cliché fail. :)
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.
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...
From the brief discussion, it sounds like it had inferior performance to the 32 bit builds, and was buggier to boot.
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.
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.
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.
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
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.