Forgot your password?
typodupeerror
Firefox Mozilla News

Mozilla Dropping 64-Bit Windows Nightly Builds For Now 224

Posted by Unknown Lamer
from the posted-from-64-bit-linux-firefox dept.
hypnosec writes "Plans for 64-bit Firefox for Windows have been put on hold by Mozilla in a bid to concentrate more on the 32-bit version. Eliminating the 64-bit nightly builds was proposed by Benjamin Smedberg, a Firefox developer, last week. Some of the reasons Smedberg cited include missing plugins for 64-bit version; lack of windowproc hooking which facilitates smooth functioning of whatever plugins are available; and the inability to work on the crash reports submitted for the 64-bit versions because they were not on high priority. The proposal, it seems, has been accepted as is evident from this bug report." The bug tracking system seems unable to differentiate between 64-bit and 32-bit builds, causing a few issues since Windows 64-bit builds are much buggier. They also intend to reintroduce 64-bit Windows nightlies some time next year.
This discussion has been archived. No new comments can be posted.

Mozilla Dropping 64-Bit Windows Nightly Builds For Now

Comments Filter:
  • by OS24Ever (245667) * <trekkie@nomorestars.com> on Friday November 23, 2012 @12:07PM (#42074341) Homepage Journal

    I am not a programmer, I'm just a systems guy. I mainly use Mac and Linux, and 64-bit is something I've Just Done for some time now since the introduction of EM64T, however the few times I need to mess with windows the way it works with 64-bit just baffles me as to how 'hard' it seems to be and how 'little' 64-bit friendly / 64-bit stuff there is.

    Why is that?

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      It's 'hard' only because it's a huge - yes really - number of lines of code. Gigantonormous numbers.

      Pointers are the main reason why software don't port between 32 and 64 bit easily. It was the same in the transitions from 8 to 16 and 16 to 32. The power of C is being close to the hardware, with less overhead. The curse of C is being close to the hardware, being harder to move to new 64-bit hardware. This is a known trade-off and it's worth it. People who don't believe it write hardware independent Java

      • by siride (974284) on Friday November 23, 2012 @12:23PM (#42074445)

        The switch from 32 to 64 is a lot less painful than 16 to 32, because the memory model didn't change.

        Even if you are writing in C, most code is probably fairly agnostic to 32- vs. 64-bit. But if you do things like cast pointers to ints, or use byte-based arithmetic when interacting with structures or unions, then you'll run into trouble. C code that conforms to the standard should be fairly portable from 32 to 64 bit, though, and this is yet another situation where the value of the standard and well-designed code pays off.

      • With OS X the main hurdle was to move from Carbon to Cocoa, as Apple dropped Carbon and never made it 64 bit. This took a couple of people a month or two at most.

        So again, why is it so hard for Windows development?

        • DLL Hell and the closed source nature of most Windows code.

          Lets say you have Windows App A, it has a tie in to Windows App B which uses licensed somecode32.dll. Unless the maker of somecode32.dll releases a somecode64.dll and Windows App B recompiled to 64-bit, Windows App A has to stay 32-bit. Since there is such an insanely huge install base of 32-bit programs that are still being used but not actively developed that Windows developers stick with the lowest common denominator.

          The other half is development

      • by Culture20 (968837)

        It's 'hard' only because it's a huge - yes really - number of lines of code. Gigantonormous numbers.

        Not quite Gigantonormous, but it more than doubles some sections with tests to see if you're running in 32bit or 64 bit, then using the proper size of variables.

        Pointers are the main reason why software don't port between 32 and 64 bit easily. It was the same in the transitions from 8 to 16 and 16 to 32. The power of C is being close to the hardware, with less overhead. The curse of C is being close to the hardware, being harder to move to new 64-bit hardware. This is a known trade-off and it's worth it. People who don't believe it write hardware independent Java code etc, and as observed, their software usually don't provide all the desired features, hence people stick with the software written in languages closer to the hardware.

        To elaborate, pointers are variables which point towards specific places in memory, and are quite useful for passing data between functions (or even other programs) without having to copy the data. A 32 bit pointer can not point to any address space beyond the 32-bit limit (4GB), so 64 bit pointers are needed in 64 bit systems, assuming they have m

        • by pe1rxq (141710) on Friday November 23, 2012 @01:17PM (#42074807) Homepage Journal

          If you use the right types in C there is no problem at all.
          No endless if statements needed.
          However the world is filled with idiots who mix integer and pointer types.

        • If one source tree is used for both 32bit and 64 bit systems, there will be the endless if-statements that I mentioned above any place where pointers are defined (and in some cases, used).

          Uh, really? Maybe I've got this wrong, but some any code I've written works just fine with all its myriad pointers when compiled in either 32bit or 64bit.

          In fact, yes, hold on:

          printf("%d",sizeof(int*));

          returns 4 on 32bit and 8 on 64bit.

          The only things I had to change in my code where some places where I'd used int as pointer offsets - I swapped those for size_t and everything was done.

    • The native Windows API was always a mess, and the 64 bits API is a case of "what were they thinking?!" even when compared to the other Windows ones.

  • Since Windows doesn't have pure 64 bit versions, there is little reason to insist on 64 bit Firefox. Unlike most other systems, almost all libraries have to be compiled into Firefox anyway so better ABI doesn't win you much, and going 64 bit has a significant memory cost -- for typical C++ code, around 33% extra.

    • by arth1 (260657) on Friday November 23, 2012 @12:51PM (#42074629) Homepage Journal

      and going 64 bit has a significant memory cost -- for typical C++ code, around 33% extra.

      Which is more than offset by not having the Windows 7 32-bit default limitation of 2 GB max per process, 3 GB max total memory.

      16 GB ECC memory should be standard now, with RAM prices as low as they are.

      • by Dagger2 (1177377)
        To be fair, a 32-bit process with the LARGEADDRESSAWARE flag running on 64-bit Windows will have access to 4 GB of address space. Even for heavy Firefox users, 4 GB of memory generally ought to be enough if you decide ignore the effects of memory fragmentation.
      • by nabsltd (1313397)

        16 GB ECC memory should be standard now, with RAM prices as low as they are.

        Unfortunately, the vast majority of motherboards sold can't support ECC memory at all.

        And, despite the low price of memory, ECC has a huge premium in price (as much as 100% for registered ECC) even though it needs only 12% more components.

        • by arth1 (260657)

          And, despite the low price of memory, ECC has a huge premium in price (as much as 100% for registered ECC) even though it needs only 12% more components.

          Compared to the price of the rest a computer, it's still pretty darn cheap. I bought 2x8 GB of 1333 MHz registered ECC two weeks ago, and it was only around $140.
          The peace of mind with ECC RAM is, IMO, worth it, especially as capacity grows and errors increase simply because there are more bits to potentially have errors.

          Anyhow, I think applications should definitely support higher amounts of RAM (and thus 64-bit), even though they should be frugal enough to run with little RAM.

    • Since windows does not have a 64bit version, there is little reason to insist on a 64bit firefox.
      Since most windows applications are 32bit, there is no reason to insist on a pure 64bit OS.

      Am I the only one seeing the endless problem here?

    • by Sam H (3979)

      and going 64 bit has a significant memory cost -- for typical C++ code, around 33% extra.

      There is no such thing as "typical C++ code" for the memory usage metric. Pointers may be larger, but a decoded 1680×1050 32-bit image takes 7 megabytes of memory on a 32-bit platform and 7 megabytes on a 64-bit platform. Remember that the web is full of images.

      I work on multi-million-line C++ projects and my personal experience indicates about 5% overhead. I'm not saying you're wrong, but you really need to back up that claim with some real life figures if you're going to use the word "typical".

      • by KiloByte (825081)

        Code that uses STL for its data structures, and doesn't hold large blobs, tends to behave in quite similar ways. For example, I benchmarked the speed difference between i396 and x32 on five separate C++ modules, and the slowest had a 20% gain, the fastest 27% (CPU) -- nearly the same considering that stuff in other languages tends to jump wildly between -2% and 40%.

        And as neighbour poster notices, Firefox's memory usage is mostly DOM/Javascript.

    • going 64 bit has a significant memory cost -- for typical C++ code, around 33% extra.

      It also supports twice the number of registers, the "basic" calling convention allows passing more parameters via registers, and no register is required to store the frame pointer (for debugging). In C++ code which it sounds like you consider "typical" (read: object-oriented), passing this around sounds a lot better on x86_64, even if they use twice the bits.

  • Bonus: (Score:3, Funny)

    by Culture20 (968837) on Friday November 23, 2012 @12:26PM (#42074467)
    That naturally limits FF's RAM consumption to the 32bit address space. Bravo, they've reduced it by 90%+!
  • by Bryan Bytehead (9631) <me@br[ ]lprice.com ['yan' in gap]> on Friday November 23, 2012 @12:27PM (#42074479) Homepage

    The one point that I find quite laughable as a reason for stopping work on it is that there are not that many nightly 64-bit users.

    Well, first, if you want to run 64-bit, you have to know that it exists in the first place. They offered a download link for awhile on the page where you could download the beta, Aurora and Nightly, but that disappeared over a year ago when I was rebuilding my computer. Not that that particular page was well known, either. I knew it was in the FTP site, I just had to look for it.

    Yeah, I understand that the compiler has started putting out invalid code for the 64-bit version. OK, well then maybe the compiler needs to be changed or fixed then?

    And browsers don't use more than 4GB?? Really?? I have the memory screenshot that shows me using 5GB of RAM under these nightlies. It happens every day and usually multiple times per day for me. It's not a bunch of tabs with media opened in them, it's one tab with Google Reader running for a few hours. Can't wait to see what happens when I switch to 32-bit, and I run out of memory before I run out of physical memory on my machine. And I've only got 8GB.

    There will be a time when they HAVE to support 64-bit under Windows. They are talking about some point in 2013. I can't believe that a period of a few months is going to make it easier. There was a recent patch when they went from 19.0A1 to 20.0A1 that made the nightly unstable in a matter of minutes. Works in 32-bit mode, but doesn't in 64-bit. Is waiting nine months later after bad patches like that getting into the main code really going to help debug those bad patches?

    • by jandrese (485)
      If your browser is using 5GB with just one tab open, then it's leaking memory and quite a lot of it. You might want to look into disabling a few extensions to see if you can find the one that's leaking.
    • by gQuigs (913879)

      Actually... your memory usage will likely be better under the 32 bit version. 64 bit will use more memory usually somewhere in the 1.5x to 2x range. I also don't think one process can access more than 4 GB of ram on 32 bit.

      I do still agree that the reasons they presented aren't very good. It doen't seem like there was any real discussion about it... All new machines are 64 bit capable and I hope installed 64 bit by default now.

    • by Raenex (947668)

      There will be a time when they HAVE to support 64-bit under Windows.

      Why is that? Even Windows 8 still supports 32-bit apps on 64-bit machines. I suppose at some point in the future they will HAVE to support it, but it isn't any time soon.

  • Sysadmin for an SMB here. We develop our own browser-based app in Flash/Flex that we use for a big part of our work. It's also computationally intensive, and I was often being asked how we could improve the performance of the application on the client-platform side. Sure, we have decent hardware, but we were developing for the standard Firefox build, and that meant 32-bit and the restrictions that go with it.

    Eventually I convinced the development team that since they had moved the backend to 64-bit code, th

    • by Anaerin (905998) on Friday November 23, 2012 @01:17PM (#42074809)
      Sorry, but Chrome is x86, not x86_64, and thus only 32-bit. The process isolation it uses means that each tab can access 2GB of memory, but the program (and the plugins) are 32-bit. The only 64-bit browsers are Opera, IE and (up until now) FireFox.
      • by Nimey (114278) on Friday November 23, 2012 @01:56PM (#42075167) Homepage Journal

        You can still get 64-bit Firefox. It's called Waterfox and tends to lag behind the official version a bit, but it's there.

        • by LoadWB (592248)

          If only I had mod points. I've been using the nightly x64 builds now for a while. I'll echo OP's statement on not easily finding the 64-bit nightly builds. I'm running a lot of 64-bit software on my XP x64 system (will be 7 x64 when I get around to it) simply because I have noticed performance increases in Firefox (with a butt-load of add-ons) and The Gimp in 64-bit. AutoCAD and Revit in x64 run like dreams, too (aside from the standard bugs.) Anyway, I'm disappointed I'll not be seeing more nightly bu

      • The only 64-bit browsers are Opera, IE and (up until now) FireFox.


        $ rpm -q chromium
        chromium-21.0.1180.89-1.fc17.x86_64

        (thought I prefer Firefox except for Google Apps)

        • by Anaerin (905998)
          I'm sorry, please let me clarify: The only 64-bit browsers on windows are Opera, IE and (up until now) FireFox. FF is still available in x64 on Linux and OSX, that support is not going away.
    • If you really cares about performance on the client side in the first place, you would never have used Flash/Flex.

      • by tepples (727027)
        I thought Flash Player supported recompilation of AS3 bytecode before browsers supported recompilation of JavaScript code. That might have been the original driver behind choosing Flash/Flex over JavaScript.
  • by mZHg (2035814) on Friday November 23, 2012 @12:58PM (#42074681)

    If you want a 64bits version of Firefox, use Waterfox :)
    http://www.waterfoxproject.org/ [waterfoxproject.org]

  • lack of windowproc hooking

    What? SetWindowLong[Ptr] hasn't gone anywhere in 64 bit Windows. If they are using SetWindowsHook[Ex], the bitness of the injected code has to be the same as the process, but this would be such a horrible approach anyway, I can't imagine that is what they are doing
  • What? Fuck off... that's the browser I use to check my forums etc. in Windows (because it's a 64 bit build). Like I'm going to stay with alpha quality code that's no longer updating.

    Oh well, if I have to use a 32 bit browser I guess it will be Google Chrome. (I don't use Firefox in Linux anymore, I do Chromium builds once a week or so)

    I don't have a build environment in Windows, that's such a pain in the ass. I just have Windows for gaming, so I don't do that stuff.

    I'm pretty much all out of uses for Mozill

  • Am I the only one to discover that Firefox doesn't play well with my window manager after the 17.0 upgrade yesterday?

    Can't resize any of the windows, and most come up tiny.

  • On my work PC I have Windows 7 x64, and starting with some version (somewhat like 14.0.2) FF had a serious bug in 32-bit version. It would just stall my computer after some time. Disabling plugins/extensions didn't help. Switched to x64 version and the problem went away.

Reference the NULL within NULL, it is the gateway to all wizardry.

Working...