Mozilla Dropping 64-Bit Windows Nightly Builds For Now 224
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.
Dear Computer Programmers: Why do this? (Score:5, Interesting)
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)
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
Re:Dear Computer Programmers: Why do this? (Score:4, Insightful)
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.
Re:Dear Computer Programmers: Why do this? (Score:5, Insightful)
Firefox already runs 64 bit just fine -- over half of Debian installations are pure amd64. The problems here are caused by quirks in 64 bit versions of Windows only.
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:2)
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
Re:Dear Computer Programmers: Why do this? (Score:4, Informative)
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.
Re: (Score:2)
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.
Re: (Score:2)
One thing that comes to mind is that afaict win64 is the only common platform where sizeof(long) != sizeof(void *).
I dunno if this is the reason for firefox's problems though or if it's just a case of noone caring to debug it.
Re: (Score:3)
Good point. I don't know about XP/7 but Windows 95 used to pass a lot of 'handles' around which were actually pointers to internal data. If the size of the handles has changed, people may have been storing them as 32-bit integers and now discovering that they're a different size in 64-bit code.
Re: (Score:2)
Re: (Score:2)
One thing that comes to mind is that afaict win64 is the only common platform where sizeof(long) != sizeof(void *).
Why is the program storing a pointer in a long instead of an intptr_t or a union?
Re: (Score:2)
I recall a programmer porting from linux to windows that decided it was a good idea to install to and write data out to a system folder (I think it was
Anyways, I suspect many of the bugs in mozillas 64-bit bu
/usr/share (Score:2)
I recall a programmer porting from linux to windows that decided it was a good idea to install to and write data out to a system folder (I think it was /windows/system32/) .. it was the author of the electric sheep screensaver that did this really boneheaded thing. They wouldnt even dream of doing something like that under a *nix, but there they are doing it on windows
What's the equivalent under Windows to /usr/share or /usr/bin or even /usr/local/share or /usr/local/bin? All Windows has for software packages that aren't part of the operating system is %ProgramFiles%, which is more like /opt in that it is divided by package at a higher level than by executable (.../bin) and non-executable (.../share) files.
Re: (Score:2)
Re: (Score:2)
Actually, wouldn't that be extremely easy to debug? Just have the custom allocator pad with 8 extra bytes, and see if everything suddenly starts magically working.
Re: (Score:2)
When targeting a non-C99 compiler (Score:2)
But why would someone ever need to make that assumption [that sizeof(long) >= sizeof(void *)]?
Because a program was written prior to 1999 when C99 was finalized, or the program is for a platform whose most common compiler was slow to adopt the new integer types in C99.
It's the Windows API (Score:3)
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.
Re:Dear Computer Programmers: Why do this? (Score:5, Insightful)
I'm not sure why a 32-bit Linux application would need a 32-bit kernel? Unless it's poking deep in the guts of the system, in which it's most likely going to be tied to a particular kernel anyway.
32-bit linux applications need 32-bit glibc (or whatever libc/library they use) to run. Both the 32-bit and 64-bit versions can be installed on a 64-bit system just fine. Most of the time you'd run without the 32 bit libraries since you use lots more space with them, and until you get in to specialized programs, most come with 64-bit versions. On an application that doesn't use rpm, or some other packaging to tell you what libraries you need, you can be left guessing on what you need to install, I will give you that.
But thinking Windows is more friendly then Linux on 64-bit is insane. The whole capture the system call and write it to a different directory thing... verses /lib and /lib64. Yea.
Re: (Score:2)
On Linux, if you had an application that needed a 32-bit system, and you had a 64-bit install, I'd tell you to reinstall a 32-bit OS.
Sounds like you shouldn't be giving advice. The correct process is to install whatever 32-bit libs you need.
Not only can I run 32-bit Linux programs on 64-bit Linux without having to "reinstall a 32-bit OS", I can run 32-bit Windows programs (via Wine).
I start with Linux nearly 4 years ago, and even then the 32/64 issue was a solved problem.
Re: (Score:2)
Get some real world experience with this.
AC Talks Out His Ass; News At 11
Re: (Score:2, Troll)
OSX didn't didn't magically recompile/emulate 64bit code. They embedded both 32bit and 64bit code into a single binary and selected the right one based on the target architecture; it wasn't free.
Feel free to continue pulling bullshit out of your ass. A 64bit binary will operate on 32bit Snow Leopard on a 64bit machine. This was done to support early 64bit intel machines running Leopard/Snow Leopard because they booted by default into 32bit OS X to avoid issues with missing third party drivers. You could force it to reboot into 64bit mode but some drivers for third party hardware would not be available. Anything like a "driver" had to be run in the appropriate kernel but applications compiled for 6
Not much point in 64 bits here (Score:2, Informative)
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.
Re:Not much point in 64 bits here (Score:4, Insightful)
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.
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
All ASUS motherboards support ECC AFAIK, as do the new AMD CPUs.
Pretty much no non-server/workstatiion motherboards for Intel chips support ECC. Asus does have the P9X79WS, though, so that's one. Although every AMD CPU supports ECC, not every AMD motherboard supports it. So, I stand by my statement that the vast majority of motherboards don't support ECC.
To be honest, though, if you don't want two or more graphics cards, there are a lot of Intel server/workstation motherboards that are great for general-purpose computing (or gaming with a single x16 card). But, thos
Re: (Score:2)
Pretty much no non-server/workstatiion motherboards for Intel chips support ECC. Asus does have the P9X79WS, though, so that's one.
Also, ASRock X79 Extreme 3 (which I wouldn't buy because it comes with Broadcom LAN instead of Intel).
And a bunch of boards that are sold as server boards, although they don't seem to have a lot of server features, and "server" seems to be used as a moniker for "supports Xeon and ECC if you so choose".
Although every AMD CPU supports ECC, not every AMD motherboard supports it.
True. I vote with my wallet here, but unfortunately so do all the people who think that $50 saved on a $800 computer that lasts for 4-5 years is a significant saving.
But IMHO, it should be standard except for
Re: (Score:3)
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?
Re: (Score:2)
It depends on your point of view if you see it as a problem. The some Linux developers see it as a best of both worlds case
https://en.wikipedia.org/wiki/X32_ABI [wikipedia.org]
Re: (Score:2)
You can't use x32 on a 32 bit OS, as interrupts or task switches won't preserve additional registers.
Re: (Score:2)
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".
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Not much point in 64 bits here (Score:5, Funny)
Bonus: (Score:3, Funny)
The reasons are stupid. (Score:4, Insightful)
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?
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Get Google to fix their piece of shit Reader. Absolutely no reason it should be eating ram the longer you use it.
Have you ever managed to get Google to "fix their piece of shit" anything?
Switching to Chrome (Score:2)
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
Re:Switching to Chrome (Score:5, Informative)
Re:Switching to Chrome (Score:4, Informative)
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.
Re: (Score:2)
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
Re: (Score:2)
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)
Re: (Score:2)
Re: (Score:2)
If you really cares about performance on the client side in the first place, you would never have used Flash/Flex.
Re: (Score:2)
Firefox + 64bits = Waterfox (Score:3, Informative)
If you want a 64bits version of Firefox, use Waterfox :)
http://www.waterfoxproject.org/ [waterfoxproject.org]
Re: (Score:2)
Re: (Score:2)
20.0a1 here. Without actually reading TFA, I wonder if this is the last version.
Re: (Score:2)
Palemoon is also x64. It is unaffected by this change.
http://palemoon.org/ [palemoon.org]
What am I missing? (Score:2)
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
No more 64 bit NIghtlies? (Score:2)
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
[OT] Firefox 17.0 on Linux (Score:2)
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.
32-bit is problematic, too (Score:2)
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.
Re:64bit (Score:4, Insightful)
It's not just about memory, it's also about an enhanced instruction set that includes extra registers, addressing modes and the removal of some old x86 cruft.
Re: (Score:2)
Well, why don't you get some software that can use it... Like Chrome, or Safari, or Internet Explorer, or Opera, or ...
Re: (Score:2)
We've had PAE since 1995, which allowed you to load 64GB of physical memory onto an x86, 32-bit machine. Sure your per-process limit is still (slightly less than) 4GB, but it'll still let you multitask several large applications (and I think some browsers have actually started breaking tabs out into separate address spaces, since apparently now web documents require as much memory to render as 3D games).
Re: (Score:2)
It sounds like the AC is in for some trolling, but he/she is kind of right in that 64-bit Windows has been somewhat of a bumpy ride compared to a few other operating systems. For Solaris, AIX, and even Linux there wasn't much of an issue in going to 64 bit a decade ago; yet even today Microsoft struggles with getting their own software onto 64 bit. For example, Microsofts own development environment Visual Studio is still 32 bit only.
Re: (Score:3)
If someone could make a compelling argument as to why it should be moved to 64-bit, I'm sure they would. Visual Studio has no problem allowing users to write, compile, and debug 64-bit programs -- I do it every day. I don't think they are even close to requiring more than 4GB of memory for themselves, so making a 64-bit version of it or most of Microsoft's own applications is just not needed, and would cause more issues, work, and overhead for nearly no perceivable improvement.
Then again, I've never had t
Re: (Score:3)
Well, that's of course a good argument. If it ain't broke, don't fix it. A more common argument would be that you want to eliminate 32 bit code in the long run. I assume that they for example have to maintain dual stacks of 32 and 64 bit versions of all their libraries, and getting rid of the 32 bit versions would be good for maintenance reasons. But that's still far away due to backwards compatibility.
Re: (Score:2)
The only reason one needs a compelling argument in the first place is because it's hard to do on Windows. On other platforms, "because it's there" was compelling enough to make it happen for not just Firefox but thousands of other applications big and small. It's not so much that there was a good reason to do so; it was that there wasn't really a good reason not to.
Actually back in the day there were a few good reason to go 64-bit. You got things like SSE turned on in compiled code if you went 64-bit.
Re: (Score:2)
The fact that there is no 64-bit MSVC compiler that can produce 32-bit binaries has certainly been a problem for a number of people. It means that trying to do PGO on a large codebase being compiled into a 32-bit binary runs out of address space. Both Mozilla and Google have run into this, for example; in Google's case the result was them not using PGO at all.
Re: (Score:2)
Re: (Score:3)
Have you ever compared the contents of the Program Files and Program Files (x86) folders?
When 90%+ of the applications on 64-bit Windows are not actually 64-bit, then AC's snark seems to have some merit.
Re: (Score:3, Insightful)
This doesn't hurt Windows, only Mozilla. Nobody really cares if their browser is 32-bit or 64-bit, but if they did, it just means they'd ditch Firefox in favour of another browser like Chrome.
Re:YAY !! DEATH BY A THOUSAND CUTS !! (Score:4, Informative)
There's no 64-bit Chrome, so this is a moot point.
Re: (Score:2)
I believe this is mostly down to the various libraries that Chrome relies on not being 64-bit clean themselves.
Re: (Score:2)
While it is true that there is no 64-bit Chrome, it spawns a separate process for every tab. Firefox crams all tabs into a single process. With enough tabs, you can use up your entire 2GB limit on memory. With Chrome, you'd have a hard time finding a single webpage that uses up it's entire 2GB addressing space.
Re: (Score:3)
You can select your architecture there, be it 32 or 64 bit. I've been running on 64-bit for quite some time already.
Re: (Score:3)
Nice rant, but it's out of date with regards to Opera.
Bringing the out-of-process plug-in architecture across to Windows and Mac also brings another advantage: the ability to run plug-ins compiled for Intel 32-bit architecture from within a 64-bit Opera process. And 64-bit Opera is the other delightful gift we're giving you at Opera Labs this Christmas!
64-bit Windows and Mac have been in the works for a while, but we didn't want to release them until we had a way of running all plug-ins that's completely transparent to the user: This is now possible with the out-of-process plug-in architecture, so here we are! The 64-bit versions of Opera offer performance improvements in some specific areas and allow Opera to have more freedom in allocating memory.
http://dev.opera.com/articles/view/64-bit-opera-and-out-of-process-plug-ins/ [opera.com]
Re: (Score:2)
Re: (Score:3, Funny)
PC deprecated in favor of what? (Score:3)
[Microsoft's] windows OS is tied to the PC and to an old 32bit architecture which are both going to be deprecated soon.
You claim that the PC will be deprecated soon. What will replace the PC as a tool for medium-duty to heavy-duty creation of works of authorship, especially for software development?
Re: (Score:3)
Re:PC deprecated in favor of what? (Score:4, Insightful)
Maybe for a short while. But even tablets are closing in on the 4 GB barrier and 64 bit ARM chips are on the way.
Windows 8 tablet or Windows RT tablet? (Score:2)
Re: (Score:3)
Re:YAY !! DEATH BY A THOUSAND CUTS !! (Score:5, Insightful)
I hope Firefox does thrive. It seems to be the best browser for web developers. I use several plugins to assist in debugging websites (Firebug and Firesizer for example), and the ability to view image info is also handy - Chrome, by default, does not make that easy.
It's possible that similar functionality is available for Chrome, but it's also nice to have one lean browser for real browsing, and a plug-in laden one for web development. IE I only use when I want to see what it breaks, although to be fair IE9 now does a much better job at rendering things the same way as Firefox and Chrome.
Anyway, I still find Firefox useful and hope it has a future. At this point in time, I can't see the lack of a 64bit version being a major drawback.
Re: (Score:2)
Chrome, by default, does not make that easy.
Actually, Chromes built-in page inspector is great. No plug ins required and all the functionality of firebug right there by default.
Re: (Score:3)
Re: (Score:2)
this just makes Mozilla look Mickey mouse, because IE comes in 64 bit and has for something like 7 years now poor lame Mozilla can't even write well enough to tell the difference between 32bit and 64bit bugs.
And yet, on a recently-installed Windows 7, there are web pages that don't work correctly when using the 64-bit version of IE.
Maybe it's a problem with plugins, maybe it's the browser...I don't know and don't really care...I just care that the web pages don't work right. I discovered this when I found out that typing "iexplore" in the Start Menu search box results in the 64-bit version being run.
Besides, who really needs a browser than can access more than 3GB of RAM? Google doesn't think that it's necess
Re: (Score:2)
Exactly... This basically smacks of "Hey, our 64 bit version is buggy, poorly supported and doesn't work right, lets stop testing it, that'll make it better".
Re: (Score:2)
Re: (Score:2)
Riiight, because this hurts Windows.....how exactly? this just makes Mozilla look Mickey mouse, because IE comes in 64 bit and has for something like 7 years now poor lame Mozilla can't even write well enough to tell the difference between 32bit and 64bit bugs.
Have you actually used the 64-bit IE? There is a good reason it's not the default binary, and that's because it doesn't "just work" as expected. I'm speaking of IE9 on Win 7 here.
Re: (Score:2)
Re: (Score:2)
Make that 3 or 4 if they someone uses Windows 8 with Modern and non modern versions. :-)
Re: (Score:2)
GNU/Linux has been stable and feature complete on x86-64 for over 5 years already, and in fact runs faster, and more stable(no PAE/memory ceiling).
Using Mozilla, Chome, and other open source browsers in 64bit are the exact same in 64 bit as 32 bit,
Re: (Score:2)
Please also note that Chrome is not available for 64 bit Windows either...
No, but since Chrome runs each tab in a separate process it has practically no memory limit (at most 4GB/process). As far as I know Mozilla announced plans to do the same in 2009 but put the plans "on hold indefinitely" = cancelled a year ago. For speed I don't think there's a major reason to go 64 bit, except maybe to win some "computing in the web browser" benchmarks with little relevance to normal browsing.
Re: (Score:2)
64-bit chrome would be largely useless. It's not large address aware, but being a multi-process browser, every tab/plugin/etc runs in a separate process, and each can independently access up to 2GB of RAM. Chrome's overall memory usage on a 64-bit system can greatly exceed 4GB without any problems.
If they need a bit more RAM per process, they can (without going 64-bit) add large address support, bumping that up to 4GB on 64-bit systems.
Re: (Score:2)
Browsers aren't actually written this way.
You'd need a browser that was somehow optimized to do an incredible amount of parallel processing to get such benefit. Plus on average the data is coming in slowly across some pipe, or being sent to a non parallelized JavaScript module (which must run synchronously to various other things [WebWorkers are the exception and very little web content uses them]) -- parallelization is really only usefully available on the per window-domain boundary (used by IE and Chrome). Also by splitting things up into distinct processes, it makes Garbage Collection easier....
What data do you think the browser is actually moving around in such clock cycles? Note that WebGL is special since it just sends all the data to the GPU which does things its own way anyway.
Fun fact: x86-64 programs have access to twice as many CPU registers as x86 programs do.
Re: (Score:2)
... and here I used up all my mod points. I don't know what their problem is, it surely can't take much to keep it compiling for x64 under Windows.
I can almost understand why it took them so long to come out with a 64 bit flash plugin (for either platform) though. Imagine what a fuckstick mess that code base would be. It's proprietary, changed hands so many times, and the result is a 10 megabyte+ monstrosity of a library (my current 64 bit libflashplayer.so is 18 megabytes, lol). It was probably a bitch bas
Re: (Score:2)
Compiling is easy in a vacuum,
Fixing all the bugs introduced by the different compiler that you haven't worked around yet, then fixing all the issues due to the 64-bit plug-ins (esp Flash) having a different set of problems than the 32-bit ones, then fixing any remaining issues due to Windows-specific code possibly making dumb assumptions about sizes of things is a different matter altogether.
Which is why 64-bit nightlies _existed_. They just don't work that well, on average.
Then the question becomes wheth
Re: (Score:2)
Because things change between them.
"sizeof int" will return "4" on 32-bit and "8" on 64-bit... When working with pointers (Variables that "point" to memory addresses), you need to make code that can handle these changes appropriately, and to change size-dependent operations so they handle multiple architectures.
On a modern language architecture like .NET, a request for an int returns a 32bit integer regardless of the architecture you are running it on and a call for a long returns an 64bit integer regardless of the architecture you are running on.
As this illustrates, http://en.wikipedia.org/wiki/64-bit [wikipedia.org] Java provides the same integer length regardless of the CPU bit width and the same with OS X and the Cocoa framework. Only windows seems to have these sorts of problems.
Re: (Score:2)
Windows? More like C.