64-bit Firefox is the new default on 64-bit Windows
blog.mozilla.org
blog.mozilla.org
Having 64 bit by default fixes such problem. That's a good move. Well done moz://a
There is a separate issue of programs that need more than a 32-bit allocation for their memory. Not many apps hit that limit so far, and it's tricky to support anyhow since you need 64-bit ints for pointers and JS doesn't support that well. wasm64 will address this eventually.
Linux also uses different directories and has "potentially a lot of other issues". Windows uses LLP64 rather than LP64[1] but IMO that's just different not clearly/necessarily better or worse.
[1] https://blogs.msdn.microsoft.com/oldnewthing/20050131-00/?p=...
But the real reason 64-bit Firefox is the default on 64-bit Linux, is that 64-bit Linux usually doesn't have the 32-bit compatibility libraries installed by default. On Windows, on the other hand, 32-bit compatibility libraries are always available.
For example - if a user only had 32-bit Flash installed and they updated or installed 64-bit Firefox, they'd be annoyed that Flash "broke". That might not be the best or most current example, but it's that kind of thing that held up 64-bit default on Windows.
The other compilers vary. The C standard only specifies that int has to be at least 32 bits. That's one of the many issues of porting from 32 to 64 bits.
That's not true for MinGW, and for good reasons (deviating from the ABI followed by the OS and all libraries would be stupid).
What is the advantage of having "int", "long" types that just give minimum byte requirements (with associated storage classes, etc.) instead of more specified types like int32_t and uint8_t? In the end you deal with fixed-size integers or not (using some bignum library), but if you deal with them you have to take their byte length into acount in your code anyway I would say (to deal with overflows and stuff).
It took a little while, but eventually C got https://en.wikibooks.org/wiki/C_Programming/stdint.h (in C99 :( ).
If it was ever so simple, specially given UB and compiler specific semantics across all those compilers and operating systems on the 90's (before C was hardly relevant outside UNIX).
stdint even includes 'int with at least x bits' & 'fastest int type with at least x bits'
The advantage is that these more specific types might not even exist. For instance, some machines had 36-bit words, so a 32-bit type would have to be emulated, at the cost of extra instructions.
What makes porting complicated in general is dealing with pointers and handles. These are 32-bit or 64-bit, depending on the architecture. Unfortunately, it was pretty common for old code to assume that they're always 32-bit, and e.g. shove them into ints (WinAPI itself was guilty of this on many occasions).
Technically, such a thing was never portable - not even with longs - until C99 brought us intptr_t, there was no guarantee that any integral type was large enough to hold a pointer. But in practice, it worked, so people did it.
A lesser issue is that the x86-64 JIT for JS was generally worse in performance than the 32-bit x86 JIT, although this has been fixed for a few years now.
It's not that Firefox couldn't be 64-bit on Windows, it's that the developers didn't feel it was ready to ship it to a large userbase.
On Mac I believe both Firefox and Safari used a separate broker process to go between 32-bit plugins and the 64-bit browser. Is it that much messier to do on Windows?
It was much easier to do on OS X than on Windows. That's primarily because on OS X, at least at the time, Firefox was a Universal Binary, meaning there were complete 32-bit and 64-bit binaries for OS X in the same application package. We had been doing this for reasons I won't get into here, but they were unrelated to running plugins with mismatched bit-ness. That being the case though, we "just" (devil is in the details) started a 32-bit child process, which had all the same functionality (e.g. plugin code implementation) as the 64-bit process, and made sure that plugin API data going between the processes was always fixed length (e.g. int32 vs plain int) so there was no misinterpretation.
Mozilla could probably have done something very similar on Windows, but they weren't already installing both 32-bit and 64-bit binaries on every Windows machine. Doing that just for the sake of plugins would, at a minimum, have been a big bullet to bite. And there was/is no nice Universal Binary package equivalent on Windows.
Also, and this gets more nitty-gritty, the NPAPI plugin API on OS X was much easier to get working across two processes of different bit-ness. This was mainly because we had recently revised the OS X NPAPI (we called it Cocoa NPAPI or something like that) and got Adobe and many others to switch. The revised API was much easier to work with. The ancient Windows NPAPI was, and is, a total f*ing mess.
At the risk of sounding cynical, some people might consider that a reason to prefer the 64-bit version. ;-)
Speaking strictly about things surrounding your code, as opposed to the code itself, there's stuff you just don't have on Linux.
On Linux pretty much everything is open source and provided by your distro, built for your architecture. The need for compatibility layers are absolutely minimal. This has a resounding positive effect in that quite a lot of things can be assumed fixed and in place.
On Windows, not so much.
Most applications are pre-built by others. Most are 32-bit. So Microsoft tries to maintain backwards compatible execution environments for both 32-bit code and 64-bit code in Windows.
This means that 32-bit processes trying to access system DLLs, will need to find 32-bit system DLLs somewhere. Same for 64-bit. So you have duplication of system-DLLs, in different folders. You can't just assume a standard, fixed path will lead you to the right place.
For the COM subsystem, all the available components an application can access is stored in the registry, alongside their physical path on disk.
You may need different DLL-files for these COM components in 32-bit processes and 64-bit processes. So now you need the registry to point to different locations based on the bitness of the application running. So yeah. Portions (but not all parts!) of the registry is also duplicated with different references for different processes.
That means that when going from a 32-bit process to 64-bit process, all things you've previously written to the registry... May not be there for you to read in your 64-bit process.
And you better make sure your installer is the same bitness as your process... Or you know what? That 32-bit installer wont be allowed to prime the 64-bit registry your application needs!
This may mean that all COM components you've registered in your installer, now is inaccessible to your (and other) applications because they are 64-bit.
And I'm sure the list goes on. These are just the most obvious non-pointer based things I can think of which complicates matters.
In short: On Windows... Keeping everything 32-bit and closing your eyes to all terrible things mentioned above will ensure your application keeps working, because Microsoft put in the effort to guarantee that.
The second you step into 64-bit, you need to have all these things solved. There's no going half-way. So most people who has little to benefit from 64-bit executables simply don't.
Yeah flash is 32 bit but flash has been dead for the greater part of that decade. Not sure how it could possibly be the case that moz was still shipping 32-bit Firefox as default until yesterday.
These are the realities of shipping for the minority not the majority. Users who are a blip for some companies end up being huge to others.
https://hardware.metrics.mozilla.com/#goto-os-and-architectu...
Example: https://blogs.msdn.microsoft.com/ricom/2016/01/11/a-little-6...
But I admit, these are the exception to the rule.
Having used both Linux and Windows in 32 and 64 bit versions - in a few cases on the same machine -, I did not notice a difference in performance[1]. If the performance hit due to 64bit is really that substantial, I could imagine the larger number of registers (and possibly larger caches) make up for that.
[1] Possibly, as so often in the days before SSDs, I/O was enough of a bottleneck that the difference between 32 and 64 bit code became unnoticeable.
Consequently, when you're shipping software for Windows, it's beneficial to have a 32-bit version to capture that part of the userbase. But since 64-bit Windows will also happily run 32-bit apps, once you have a 32-bit version, there's no particular reason to have a 64-bit one. The only time you get something from 64 bits is when you need a lot of memory, which most apps do not. On the other hand, by having a single version, you simplify the acquisition and installation story for the users, cut your testing matrix in half etc.
Hence, most Windows software is still 32-bit.
And saying the flash has been dead for the greater part of a decade is just completely wrong. You have to be just really, completely out of the loop if you think that applies to any kind of reality for general users.
32-bit applications on 64-bit Windows can access a full 4GB virtual address space (if they are compiled with a special linker flag) without needing the 3GB Windows boot-time flag.
https://msdn.microsoft.com/en-us/library/aa384271.aspx https://msdn.microsoft.com/en-us/library/aa366778.aspx
>> 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set
While we are at it. The flag is a bit in the header of the .exe file. It should be set at compile time in the visual studio option, but it can be set into any file really with an hex editor.
Don't expect to be able to use the 4 GB even with the flag. There is a lower hard cap that depends on the version of windows.
When I write C++ code that deals with large datasets, I try to avoid large continuous buffers as much as possible. For cache locality, an aligned 1GB buffer is practically the same as a set of 64 aligned continuous buffers, 16MB/each. You’ll only hit RAM latency when crossing the boundary between the buffers, i.e. only 63 times through the whole 1GB of data.
One problem is std::vector. The standard says the whole vector must be continuous, i.e. to split large buffer into smaller chunks, one needs to implement a custom container on top of that.
Apparently, authors of C++ think the problem will go away by itself, with the switch to 64-bit platforms.
Any reason to do so? It'd have to be some fringe use case of '<4GB RAM system & user doesn't need fast codecs'. If it's a closed business environment I'd imagine they're on IE
Maybe most importantly they just don't want to assume, at their scale, that there isn't at least one user that might need some time to be able to move to the 64-bit builds for one reason or another.
Users with <= 2GB can still install 64-bit Firefox if they really want to by downloading the 64-bit full installer instead of the "stub installer" (a tiny downloader that detects 32- and 64-bit OS and downloads the appropriate full installer). Likewise users with > 2GB can download the 32-bit full installer, too. We wanted the Firefox installer's default to provide the best user experience, but still give users the option to run the (32- or 64-bit) application of their choice.
For comparison, 64-bit Chrome's minimum memory requirement is >= 4GB.
Not officially (there is no memory system requirement): https://support.google.com/chrome/a/answer/7100626?hl=en
https://chromereleases.googleblog.com/2017/05/stable-channel...
[0] http://www.computerworld.com/article/2493395/internet/mozill...
[1] http://www.computerworld.com/article/2494189/internet/mozill...
That said, kudos for making this the default.
They only just dropped support for XP and Vista in February...
1. restart Firefox, enter 'about:crashes' in the URL bar
2. find the report ID that corresponds to the crash
3. submit it as part of a bug report to Mozilla's Bugzilla
My crash problem was diagnosed within a day and fixed.