Slashdot Mirror
Mozilla Dropping 64-Bit Windows Nightly Builds For Now
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.
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?
As a rock-in-roll Physicist once said, No matter where you go, there you are.
OS24Ever and I composed the same question at the same question. Reply to his post above. :)
I still think Firefox is one of the browsers to have: of all the browsers developers, they really care about freedom on the web.
Temporarily abandoning the 64bit Windows builds is more of a lack of resources than poor development.
Please also note that Chrome is not available for 64 bit Windows either...
--
The world is divided in two categories:
those with a loaded gun and those who dig. You dig.
same time*
"They also intend to reintroduce 64-bit Windows nightlies some time next year."
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.
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Only for people who buy into propaganda like yours. It's still the most stable, feature-rich, and fastest browser out there. Of the two major alternatives, IE is slow and buggy, and Chrome, while flashy and boasting a much smaller footprint, has compatibility and stability issues. Most of the flak FF gets is just the kind of trash-talk that comes with being best-of-breed, and anyone who not only agrees with it but also repeats it is going above and beyond the call of stupid.
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 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.
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?
Because most programmers in the last 20 years of x86 PC development have used data structures that are designed for 32-bit systems and switching all of those to take advantage of (or even be compatible with) 64-bit systems is a challenge.
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.
this is where the programmer mantra of "dont reinvent the wheel" catches up to the real world. We have hotrods sporting flintstone rock tires because hey why reinvent the wheel? redo all the memory management and asorted libraries just so you can have more than 3gb ram? maybe next year.
remeber. 640k ought to be enough memory for anyone.
That naturally limits FF's RAM consumption to the 32bit address space. Bravo, they've reduced it by 90%+!
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?
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?
Bryan
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Mozilla use C++ not C which if written properly shouldn't have any issues. At work we just ported a giant (1M~ lines) C++ codebase to 64-bit and it only took us about two weeks -- most of which was spent cleaning up third party components which relied on C-isms.
Microsoft took a different approach because there is very little hardware abstractions in their code base even within the Win32 API. They run their code at a much more bare metal level and so you cannot run 64bit apps on a the 32bit version of windows even if you have a 64bit machine. Microsoft even has its own separate API layer that only exists on the 64bit version to run 32bit apps on it. OS X and possibly linux seem to be able to run other bitness apps pretty seamlessly.
Jesus was a compassionate social conservative who called individuals to sin no more.
Really? That's news to me in the past 12 months since I switched from Firefox to Chrome. What compatibility & stability issues would these be then?
Your answer doesn't work since Firefox for 64-Bit Linux has no issue. We need an explanation for why it's hard to code for 64-bit *Windows*.
Many popular plugins, anything incorporating silverlight, CAC-enabled websites, various NVidia software, various antivirus/firewall packages... you could just Google it; there are lists out there, I'm sure. Of course, that wouldn't have been quite so showy and presumptive, forcing people to climb your hill rather than the reverse. Your next step should be to present personal anecdote as a valid counter...
To be fair, Chrome is a good browser, but it's just not as "complete" as Firefox -- though that's understandable, since Mozilla has been at it longer. Not trying to undercut what is to some a valid alternative... just giving the facts.
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.
Rethinking email
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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.
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, that the client runtime environment should be there too, and so we optimized the frontend for Chrome (which obviously, is 64-bit, with Flash built in). The speed increase wasn't phenomenal, but it WAS noticeable. Now I'm even more glad we made this change.
If you want a 64bits version of Firefox, use Waterfox :)
http://www.waterfoxproject.org/
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.
Live today, because you never know what tomorrow brings
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 more than 4GB RAM (often including video RAM; found that out the hard way). 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). And of course it affects some bit shifting, etc. This is on top of endianness, which is a whole mess unto itself.
There's no 64-bit Chrome, so this is a moot point.
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.
Micro$oft is stuck in the past. Their windows OS is tied to the PC and to an old 32bit architecture which are both going to be deprecated soon.
Another clueless AC.
I believe this is mostly down to the various libraries that Chrome relies on not being 64-bit clean themselves.
Yeah, I had a sig once; I got bored of it.
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.
And I hate to break the news to ya, but most Windows users have no clue if what they are using is 32 bit or 64 bit nor do they care, it "just works" either way and that is all they give a shit about. Besides most won't notice this as they've switched to Chrome as the falling numbers clearly indicate.
As someone who used and advocated Firefox before it was even called firefox frankly.....sigh, the company just seems to be a trainwreck ATM. They've been all over the place instead of focusing on their browser which IMHO has gone to shit since around V6. I have to support plenty of low power devices and older office boxes and frankly Mozilla Firefox is just god awful on anything less than a dual core,especially if you have a decent amount of bookmarks, as it'll slam the hell out of the CPU when you do...well pretty much anything. This is why I moved my customers over to Comodo dragon (Chromium variant) several versions back, because between the UI changes, the bugs, and the CPU and memory usage frankly Firefox can't hold a candle to anything Webkit based, it just can't.
So frankly this doesn't hurt Windows in the slightest, it just makes Mozilla look lame but since more and more are jumping on Chrome I just don't see this affecting too many people.
ACs don't waste your time replying, your posts are never seen by me.
As a Linux user, I find it quite strange and absurd, that nearly a decade after 64 bit processors were first built into consumer PCs, there still is some reason why somebody would not do 64 bit.
My Firefox on Linux has always been 64 bit. And back in the days, when the (by definition) shitty closed-source plugins, like Flash, still failed to be 64 bit, we simply put a nsplugin-wrapper around it, and the problem was solved.
This whole thing is silly. And as a programmer, I find it even more silly.
There just is no excuse for a 32 bit version to even exist anymore, unless you're completely and utterly incompetent as a programmer. (Obviously not including those programming for limited 32 bit embedded systems, etc.)
Yes, Mozilla devs. I mean you. You make us programmers look like idiots. Stop it. And stop making excuses to hide your FAIL.
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.
Secure messaging: http://quickmsg.vreeken.net/
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
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
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.
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.
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.
systemd is Roko's Basilisk.
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 Mozilla Firefox. I don't even like it anymore, with the stupid things they've done and the user interface etc. They even keep removing about:config options.
Somebody notify this gentleman about the 64 bit versions of Windows which most people use.
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 to try and debug one of my programs that required more than 4GB of code or data, so maybe there is an issue somewhere than I am not aware of.
OMG. Where will you get your untested, bleeding-edge technology now?
I find it laughable that you think this is a big deal.
Unless you're using Linux/GNU which is going on 20 years of being portable. For fuck sake they not only go 32-bit to 64-bit they go to completely different architectures like ARM.
The problem with Windows is that it's not just about ABI when you change architecture. If you go from a flavor of x86 to ARM you get a completely different API as well as a different ABI. Even if a function has the same name and parameters it's probably going to do something different. It becomes an unmanageable mess of #ifdef's if you try to reuse the same code. You practically have to have independent code bases for every architecture you try to go to on Windows.
[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?
... 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 bastard to get to compile at first.
Firefox has no excuse for not having 64 bit builds available. (Yes, binaries. It's a different environment. More homogeneous, which makes it easier for them, but it's also not so easy for Windows users to set up a build environment to compile their own)
There are only 32-bit versions of most browsers for Windows... Opera for example has 64-bit versions for Linux and FreeBSD, but not for Windows.
I've always been a bit puzzled as to why though.
The arch foe.
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?
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.
Sigs are so 1990s. No way would I be seen dead with one.
Go join the other casuals in seething over rounded edges.
what exactly is the difference between the two?
You people are so full of shit. There's more to it than just memory use. (I don't give a fuck anyway, my browser can have 8 Gb of RAM if it will take it)
Browsers are one of thing things that DO benefit from a 64 bit build because they handle relatively large amounts of data and can do it with fewer clock cycles.
Stop spreading FUD, you apologist for lazy cunts.
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.
The arch foe.
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.
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 necessary, either.
Windows drastically changes the behavior of functions when it goes to another architecture. It's not like other development environments where you can just recompile. You have to go to each API call and make sure it still does the same thing.
IF they actually cared about 32-bit vs 64-bit browser thing, then other things would be considered as well, like privacy, where Chrome is utter crap.
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.
It was easier than that on Windows -- almost none of the APIs changed! You just switch the compiler to build 64bit. If your app didn't work, it was because some dumbass programmer wrote crappy code (e.g. assuming pointers are 4 bytes), not because Windows made it hard.
luser@HAL:~$ iceweasel -v /bin/sh -c iceweasel /usr/lib/iceweasel/firefox-bin /usr/lib/iceweasel/firefox-bin /usr/lib/iceweasel/firefox-bin: symbolic link to `../xulrunner-10.0/xulrunner-stub' /usr/lib/iceweasel/../xulrunner-10.0/xulrunner-stub /usr/lib/iceweasel/../xulrunner-10.0/xulrunner-stub: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xefc8e0b22b6eb68c983888da80a2264e9a91af52, stripped
Mozilla Iceweasel 10.0.11
luser@HAL:~$ uname --all
Linux HAL 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
luser@HAL:~$ ps -ef | grep iceweasel
luser 1037 602 0 20:06 pts/3 00:00:00 grep iceweasel
luser 32247 32160 0 19:45 ? 00:00:00
luser 32248 32247 10 19:45 ? 00:02:04
luser@HAL:~$ file
luser@HAL:~$ file
In your face bitches !!!
p.s. :D
Because the person who wrote it (incorrectly) assumed that the size of a pointer would always be the size of a long.
The IDE may be 32 bit, but the compilers and tools that do the actual work are 64 bit. Since the IDE is just a front end for the compilers and tools I don't see a big reason for them to move the IDE to 64 bit.
-1 overrated isn't the same thing as "I disagree".
It sure as fuck hurts us Mozilla 64 Nightly users. I've been using it for more than a couple of years, and with a few exceptions its tended to be better than the release version since shit doesn't stay broken for as long and I've only had a couple of DOA drops, including this morning.
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 time in performance sensitive code that's been 'hacked' in such a way that it only works on 32-bit systems. The time involved to un-fluck it isn't worthwhile for a lot of developers to fix currently.
Unless you write 64bit-32bit plugin thunking glue, you're asking for users to use a browser which doesn't have the plugins they expect. When things in their browser are missing, they blame the browser (and they aren't entirely wrong since the browser could support this thunking).
There isn't much pay off for 64bit browsers on Windows. What IE and Chrome did - parent process + content child processes addresses the main issue - memory limits. Mozilla implemented this for Mobile but never finished the work, so it isn't present in Desktop Firefox.
Most of that is a loss actually. The memory footprint (bigger pointers, bigger code size) hurts your CPU instruction cache/memory cache more than you get benefits from registers (some of which are actually available anyway).
The bigger problem is that you have to write a JIT/VM for 64bit and get it to be as good/better than your 32bit JIT/VM, which takes a lot of work.
Visual Studio is in the same boat as Firefox / most Windows browsers (and Office suites too) - there are lots of plugins written for it which are 32bit. In order for it to make sense they'd have to somehow implement thunking for the 32bit plugins, otherwise the things people *use* in Visual Studio (the plugins) wouldn't work, and they'd complain about missing features / broken stuff / being deprived of what they paid for (those 32bit addins).
Because writing new software that requires an emulator to even function on your own OS is the epitomy of laziness and inefficiency?
There are way fewer plugins for OS X than there are for Windows, and most of those have 32bit and 64bit versions.
If you switched to a newer OS or a newer Office suite or a newer Whatever and you *lost* functionality, would you be happy?
Most Windows plugins don't have 64bit versions, and many which have them aren't installed on systems (because they're distinct installations - would you appreciate downloading 10mb extra data you never use - monthly?).
This actually helps Microsoft. The stable browser for Win 64 is now IE. I dropped FF as default when they lost control of Flash audio volume. Every time I went back to check the latest release of FF (thinking surely they would fix a bug that cranked the volume up when watching video and playing so many web based games) not only was the issue not addressed but the browser itself got very unstable. I have spent months getting people back off of FF after spending years getting them to switch to it in the first place. When someone calls to say FF keeps crashing or to bitch about extremely loud videos or games I just send them to IE because I don't have a fix for them... Why not turn them on to Chrome? Because doing that with FF bit me in the ass. Also not wild about Google having every little scrap of our lives. I'm now trying FF 17 but the Flash volume is still broken so it's not my default browser. Ever since Chrome came out FF seems to be doing a "Me Too!" game, right down to version numbering, I miss the days when they were innovating ...
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
But why would someone ever need to make that assumption?
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.
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.
A good justification for supporting 32-bit builds is supporting all those people still running 32-bit Windows. Call it lowest common denominator. You wouldn't understand backwards compatibility because Linux is shit in that arena, even Debian with it's "longer" release cycle. XP lasted so long, I'm sure that also delayed 64-bit adoption.
It's not a big deal in many cases whether an app is 32 or 64 bit. Firefox maybe it is because it's poorly architected and could do with a bigger memory space. In many cases there is no benefit from a native 64-bit app.
I'm afraid you can't really criticise anyway when when I can't run Lightroom on Linux, yet it runs for fine for me as a native 64-bit app on both Windows and OS X.
http://appdb.winehq.org/objectManager.php?sClass=application&iId=5839
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".
Well, why don't you get some software that can use it... Like Chrome, or Safari, or Internet Explorer, or Opera, or ...
Incorrect. Check the download link, and select more options.
You can select your architecture there, be it 32 or 64 bit. I've been running on 64-bit for quite some time already.
Manuals are your last resort only
I think first of all you're overstating this. It's not like porting to 64-bit Windows suddenly makes up down, and right into left. This is a huge exaggeration.
You're also understanding the differences on Linux. I remember porting a user mode application to PowerPC Linux in the 90s and a lot of things were missing. I've also heard horror stories about fragmentation on ARM.
And as a trivial example, just look at the list of syscalls in each arch. They diverge.
There is Win64 version of Opera now. It can be had directly from the download page. It even works with 32-bit plugins.
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/
Do what thou wilt shall be the whole of the Law
..because when a developer uses windows, they suddenly do really stupid shit.
/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...
.. which I suspect is likely considering their battle with memory leaks .. so it allocates an extra sizeof(awesomeness) and returns (byte *)pointer + sizeof(awesomeness) .. well thats fine in win32, but can break in win64 if the resulting pointer makes it way to a picky api that require alignment to the 16 byte boundary expected on 64-bit systems.
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 build that arent in the 32-bit build stem from the fact that in win32 the malloc alignment is 8 whereas on win64 the malloc alignment is 16, and that some API calls expect pointers aligned to these.
So suppose they have a custom allocator that prefixes memory blocks with 8 bytes of awesomeness (reference count, etc..)
If the picky api raises an exception then its easy to troubleshoot and solve, but not all api's are allowed to throw exceptions at their callers, so instead they return an error code that was perhaps unexpected and thus maybe handled improperly and now its not an easy troubleshoot, instead its a debugging nightmare.
"His name was James Damore."
I started using the 64-bit version because the 32-bit version frequently hits 4GB of memory usage and crashes. I've seen the 64-bit version over 16GB on my 32GB system. This is a problem that Chrome does not have, but Firefox has some extensions I really like that Chrome lacks. As long as I can continue using the 64-bit nightly that I'm currently using I guess I won't really care, but this seems rather short-sighted.
Handles have indeed changed from 32 bit to 64 bit, but MS has promised that the value saved in the handle will never use more than 32 bits, so it is still "safe" to cast it into a 32 bit variable. However, it is bad practice.
The truth may be out there, but lies are inside your head
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.
Do what thou wilt shall be the whole of the Law
A Windows 8 tablet is still a PC; if the PC is deprecated, the Windows 8 tablet is also deprecated. A Windows RT tablet isn't useful for software development without a very expensive sideloading certificate.
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.
Do what thou wilt shall be the whole of the Law
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.
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. Many of the 32-bit distributions were still being built for i386 compatibility and as such weren't compiled with such niceties. Now days everyone is targeting at least i686 processors in their 32-bit distributions so it's not as big of a feature gap.
I want this account deleted.
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.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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.
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.
Do what thou wilt shall be the whole of the Law
I wonder what would happen if the Chrome developers wanted to utilize OpenCL at some point. Same goes for Mozilla.
Some of the reasons Smedberg cited include missing plugins for 64-bit version; ...
So now at Mozilla, increased security is a bad thing?
syscalls aren't meant to be portable. That's why modern OSes include libraries.
this is a great post; thanks! Saltele
of all the browsers developers, they really care about freedom on the web.
They should adhere to open web standards then, instead of imposing their own.
Looks like the costs of a "free" browser are pretty high. Best to just stick with IE, at least support doesn't get thrown out the window when it's not convenient.
Does anyone other than Microsoft offer a 64-bit browser? Even then, MS provides both and the 32-bit one probably looks safer to most people since it's just called "Internet Explorer". The other has 64-bit appended to it which means it probably looks just different enough to scare off the clueless.
So it Google losing it for not having a Windows 64-bit browser? You're right MS has a 64-bit browser but offers the 32-bit one along side and it's possibly the default one as well. IE is the one that looks like a mess by offering two products that do the same identical thing and only serve to confuse people that don't know why they have two internet explorers and what the 64-bit version means to them.
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.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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).
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
Oops. Forgot something.
2215, one of the three predicted aforementioned events coincidentally does that which seemed formerly impossible, namely, it results in the effective cancellation, in the middle of its 227th season, of The Simpsons. As the end of all life as we know it will be fairly abrupt, the final episode will appear hastened, and millions of years from now, when distant aliens learn to send and receive radio signals, some might figure out how to decrypt our television signals, and end up watching so much of our television. They will be disappointed in the slap-dash, rapidly concluded series too. Maggie will still have had virtually no lines.
Give Mozilla some credit? Firefox is leaps and bounds improved over the past year compared to what it was.
After I posted the ram usage story last summer (Firefox won) as people kept saying it was bloated, I started using Firefox for the first time in over a year. It has improved dramatically. ... wow. IE was better just a year and a half ago.
Yes Firefox 4.0 was so bad I started using IE 9 back in March 2011. Sigh
I didn't trust Chrome rendering sites properly yet as I only knew one person who used it back in 2010 before it exploded later in 2011.
I have Firefox 3.6 on a VM to test website development work on a home project as many corps still use that dinosaur. It SUCKS Badly. I never realized it back then because that is what all slashdotters used since we left IE 6. It is sluggish, the page goes clip clip clip when I hit the up and down arrows etc. 4.0 and 5.0 were twice as bloated and borderline unusable on an AMD turion from 2007 notebook.
Fastforward today and Firefox 17 is freaking fast, the javascript interpretter is 2x as fast. Firefox 19 supposed to be even leaner and be the fastest browser out there. Firefox 17 runs on this same notebook snappy and well.
My only gripe left is that it is unsandboxed and therefore not as secure. Flash now is sandboxed THANK GOD. But other than that Firefox is becoming good again just like IE is improving but at a much faster rate.
FYI the 64 bit of IE sucks and Microsoft recommends testing only. It can't utilize Chakra (IE 9s/10s javascript engine) properly and is neutered or runs IE 6 - 8 engine! Perhaps someone more knowledge can comment on this? 32-bit to play it safe is the general rule and what sites like www.zdnet.com recommend.
http://saveie6.com/
Make that 3 or 4 if they someone uses Windows 8 with Modern and non modern versions. :-)
http://saveie6.com/
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 64bit could run on the 32bit kernel.
Jesus was a compassionate social conservative who called individuals to sin no more.
You would only try padding by 8 extra bytes if you knew that that was a problem to begin with, so no need trying it.. you just do it at that point. Its when you have no idea why the program is behaving incorrectly, not doing what its told, that its now a nightmare that does not suggest 'pad by 8 extra bytes in that custom allocator we wrote 6 years ago that never ever gave us a problem before'
"His name was James Damore."
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 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.
Jesus was a compassionate social conservative who called individuals to sin no more.
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.
Armchair Linux vs. Real World ... why are there still i386 distributions of the most recent Linux server distributions and Windows? They are not free to maintain. Why do you have to make a decision at all? There's no reason for a system install to come in the two different flavors. These vendors aren't doing it to spare a company some measly GB of disk space or download bandwidth for the 64-bit blobs you don't need. They aren't doing it because of the prevalence of 32-bit hardware in today's data centers either, they do it because big ISV's need it, and you can't install their systems ONCE and run them in 32-bit mode.
If Oracle or SAP says it runs on RHEL 5 i386, you install it on RHEL 5 i386, period. If there was ONE RHEL 5/6 install, and it could just boot into a 32-bit kernel, PROBLEM SOLVED, none of this "linux32 bash" workaround crap. I don't care how trivial it sounds, the reality is GO MOAN TO ORACLE, SAP AND OTHERS.
For Solaris and OS X, you didn't install 32-bit Solaris or 32-bit OS X, you just installed them. It booted into a 32-bit kernel if you needed it for whatever reasons. But that was the experience, ONE install.
"Capture a system call and write to a directory" - I'm sorry, WTF are you talking about? I can't find anything substantially different between how the two implemented x86_64 support.
Windows? More like C.
Kill off the 32 bit version.
Plugins not written for Chrome don't work with Chrome? You don't say?!
The rest appear to be Windows specific problems. I'd suggest your problem appears to be Windows.
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.
Get some real world experience with this.
RHEL6 i386 doesn't exist for shits and grins, it doesn't exist due to the plethora of old systems needing to run new software. It exists because ISV's need it. Four years ago you MIGHT have convinced me we still need new i386 OS installs because of some actual 32-bit hardware in use at the time. Today, forget about it. i386 Linux is probably 99% of the time running on x86_64 hardware today, and it's for applications that need it.
Four years ago, we should have been able to boot ONE RHEL install into either 64 or 32-bit mode as needed.
I can tell ya what the problem is friend...its gecko. you look at the history of Firefox and up to about FF 4 every version got better, memory got better (although they royally pissed me off by going "La la la we don't leak memory" only to turn around and say "We fixed the memory leaks!") CPU usage got better, extensions got better...so what happened? Simple they started to try to match Webkit features by just bolting them onto gecko and the simple fact is gecko just wasn't made with those features in mind so naturally bolting on advanced features sucks. If you try ANY of the webkit based browsers it is just not funny how much better they run, i personally give Comodo Dragon to my users but frankly ANY of the webkits, Safari, Chrome, Chromium, Dragon, they all just run rings around FF now.
And as someone who has to support low power devices like netbooks/nettops as well as older office systems i can tell you that since FF V5 the performance on low power devices blows chunks. For testing I use a circa 2004 Sempron 1.8Ghz I use as a nettop at the shop (37w under load, idles around 20w) and my own Asus EEE with an E350 dual core and here is what I found: While I got with multiple tabs and even SD video on ANY webkit based on either of those machines since FF V5 Firefox is completely unsuitable for purpose on the Sempron, SD video is a slideshow and nearly every action you do in FF will cause the CPU to spike to 100% and cause the UI to become unresponsive, and on the netbook I get nearly an hour longer on the battery simply by not using Firefox.
So I really hope they fix it, as there is a couple of the Firefox extensions like NoScript that I miss, but between the missing security features (Low Rights Mode has been out since 07, chromium based have supported it almost from the start while FF still doesn't) and the frankly just awful performance right now I have NO choice but to steer my customers away from FF.
BTW anybody know of a Chrome extension that will make downloading YouTube videos as simple as "Download as MP4 and FLV" for Firefox? The few hold outs I have just love that extension but so far i can find nothing that works as well, so I have to give them IceDragon with that extension installed and then let them use Dragon proper for their day to day surfing.
ACs don't waste your time replying, your posts are never seen by me.
"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."
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, if not faster.
Microshaft, like usual is playing catch up. This hurts MS, because its another great reason to switch to linux.
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.
Chrome and Safari have full javascript debuggers built in, without any adding any plugins. And it's much better than FireBug which actually causes more problems than it solves.
They are far better for web developers than FireFox. I don't know anybody who works in the industry and is using FireFox. Everybody was using it years ago, but now it's all Chrome or Safari.
Internet Explorer also has a pretty good debugger built in these days. If anything, FireFox is now the *worst* major browser for web developers.
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.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
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.
Get some real world experience with this.
AC Talks Out His Ass; News At 11
Sheesh, evil *and* a jerk. -- Jade
I stand corrected... Why is that question still in their knowledge base I wonder?
The arch foe.
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.
Sheesh, evil *and* a jerk. -- Jade
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.
If the user wasn't running Windows, there wouldn't be a problem in the first place. Your premise is faulty.
Responsive Design View looks like it makes Firesizer unnecessary. Firebug's functionality is also largely in Firefox by default now, though it may not have all the features.
The idiots causing the Firefox problem are another class of idiot altogether. Almost all JIT compilers used for browsers and the Java bytecode itself assumed a 32-bit address space. Linux had to introduce a horrible kernel hack which bids farewell to any hope of VM security to let all this shattered shit work. Some have improved and now can run without it.
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 whether to make (and test, which causes even more load on the test infrastructure) these builds, which no one plans to ship to actual end users anytime in the next 6+ months. That's what the discussion was really about: does Mozilla keep spending time keeping these builds limping even though they don't have the time to make them actually tier-1, or do they just stop doing them for now and start again when they have the resources to actually do it right?
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.
I used to work with a guy like this. Last I heard he had to re-write (again) all of the code to take care of it. The solution was quite simple (I told it to him no less than 5 times). Yet he continued to do it the wrong way. Why was he doing it this way? Arrogance or stupidity I cant tell. He would not listen to anyone else about 'his project' (even though I wrote 50% of it and worked on it 5 years before him). When he is rewriting it again next year for some other reason and still having the same issues I will again tell him the solution and he will ignore it again. But what do I care he is the one who is pulling the 80 hour weeks to make it work as he is SURE he can make it work this time.
Talking about Oracle or SAP as a Linux problem is odd, they are professionals at making large, expensive, and at many times, very fucked up software.
Also, http://scn.sap.com/docs/DOC-28792
"Why does SAP de-support 32-bit server operating systems for new releases from 2007 onward?"
I think you may be suffering from a case of "I don't know what I'm talking about".
Then again, since I'm not an armchair administrator and work in the real world I tend to know the software requirements of both the 32-bit and 64-bit packages of the software we use for both Windows and Linux.
I like how you continue to ramble on about v4 and v5 as if a low point forever defines all future versions of the browser.
Remember kids, hairyfeet is a senseless troll.
Windows? More like C.
No. Like others have said, the only reason code breaks when it moves between architectures this similar is that the author did something obviously stupid, like casting between unrelated types.
An OS may have interfaces which encourage you to do stupid things, like the Unix ioctl() is-this-an-integer-or-pointer thing. Perhaps Windows has more of this?
Its not the lack of 64bit that is gonna kills it, its the performance. take something like Process Explorer and have it set to show you via the system tray what is going on as far as CPU/RAM/HDD (its in options>tray IIRC) and then run ANY webkit and FF side by side and see for yourself. Hell I can take a low power machine from 8 years ago and still run multiple tabs and even SD video and its just fine in Webkit, the video is smooth and the UI responsive, the exact same pages and video in Firefox? It'll spike the CPU so badly the entire UI becomes unresponsive (which is why you need the tray app because when FF does this you aren't gonna be switching) and if you are on a laptop or netbook all those spikes equal worse battery life.
Like I said I REALLY wish this weren't so, I used FF before it was even called FF and I used the Moz Suite before that, but its obvious to anybody with eyes the future is more and more laptops and low power devices and in that crucial arena FF just blows chunks and again i think it comes down to gecko. gecko ran fine when they were doing their own thing, but ever since they've been trying to match Chrome feature for feature by just bolting shit onto Gecko performance has gone WAAAAY down. I would say gecko needs a major rewrite, build a new gecko with sandboxing and isolation with a focus on low resource use OOTB, because as it is now anything webkit based just blows it out of the water.
ACs don't waste your time replying, your posts are never seen by me.
Maybe he's doing it for job security.
Table-ized A.I.
You are mixing up different things.
A 64-bit binary will work on Snow Leopard running a 32-bit kernel, because all the userland libraries it requires are available as 64-bit versions, embedded next to the 32-bit ones. As such, even Snow Leopard with the 32-bit kernel is not really a 32-bit system - it's supports 32-bit and 64-bit user land, and (by default) runs a 32-bit kernel.
Get some real world experience with this.
RHEL6 i386 doesn't exist for shits and grins, it doesn't exist due to the plethora of old systems needing to run new software. It exists because ISV's need it.
No, 32 bit software runs fine on 64 bit systems. It's exactly how mr_playboy described it.
64 bit capable cpus are certainly the norm now, but 32 bit cpus aren't quite as rare as you make it sound. What was it, 2007 or 2008 that most of the Intel chips sold for desktop PCs and Macs were finally x86_64 capable? Five years is a long time -- but it's not *that* long. Lots of those older boxes are still in service today.
As for people running 32 bit OSs on 64 bit hardware, there's a few reasons they do this. 1) On Windows, 64 bit can be a big pain, especially if you've got XP or older. 2) if your system has 3 GB or less memory, running a 64 bit OS doesn't really provide that much of a benefit, and can in fact perform more poorly than 32 bit code would (as 64 bit systems require more memory to do the same things, as pointers are twice as large.)
Perhaps there is some software that does work on i386 RHEL6 and not on x86_64 RHEL6 -- but I've never encountered it. You install the appropriate i386 libraries and stuff just works. The only place I'd expect that might have problems would be anything that's really low level -- kernel modules, for example. But even then, x86_64 is so popular now that anything that's still supported should be ported to both and should have been years ago. If you're running really old software that's no longer supported and it requires kernel modules -- then OK. (Though then the odds of it working on RHEL6 of any architecture seems to be quite low as well.)
In that specific example: because Microsoft doesn't do C99 and thus there is no intptr_t.
However in general it's just bad code, sometimes caused by bad programmers.
Solaris "solved" the 32 / 64 bit issue the same way OS X did: a 64 bit kernel with an entirely 32 bit userland. OS X doesn't do this anymore but OpenSolaris did for quite a while. I haven't checked if this is still the case in the most recent OpenIndianas. So the seamlessness that you are referring to is simply a matter of adopting one as opposed to the other. This also limits the total address space for any given process to be the 4 GB limit. This can be problematic for something like a CAD or 3D rendering package, in which consuming 5 or 6 GB even with just memory mapped IO is the norm.
And for what it's worth, all the people saying that chrome is 32 bit only, that is likely the case only for windows:
file /usr/lib64/chromium-browser/chrome /usr/lib64/chromium-browser/chrome: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
Even with all of the asm included in the chromium source code it can still be built cleanly as 64 bit. Of course the same can be said about the Linux versions of Firefox, I suppose. I too am baffled why 64 bit windows support is this complicated. When developing for Windows I find all sorts of weirdness between their 64 bit and 32 bit compilers. I found the 64 bit C compiler strict about where declaring string buffers (had to be at the beginning or it wouldn't compile). The 32 bit compiler of the same version of Visual C compiled and ran the code just fine.
No. On Windows, sizeof(int) == 4. Always. sizeof(long int) == 4. Always. To get a 64-bit int, you must declare it as "long long."
If you're using C++ correctly, the move from 32 bit to 64 bit should be a re-compile. The trouble usually comes from programmers who do idiotic things like casting pointers to integers and who rely on unspecified or implementation-defined behavior.
I believe there's offset_t for offsets and size_t for sizes.
This fact is especially interesting when you look at the V8 source code, a lot of which makes use of SIMD by either inline asm or separate asm files for things like jpeg rendering. A lot of this is pulled from libjpeg turbo and other libraries, but there is a fair bit of that going on.
You'd figure with all the backward-compatibility built into Windows there would be a way to call 32-bit libraries from a 64-bit OS, similar to this: http://en.wikipedia.org/wiki/WoW64
WOW64 works because it limits itself to translating kernel function calls, program entry points, and does some CPU mode switching stuff. If you wanted to be able to use any 32-bit library in a 64-bit application then you'd need to create similar wrappers for every library. In theory that can be done automatically, however it's probably also highly error prone. Microsoft, despite what people think, make a lot of effort maintaining backward compatibility; however there comes a time when pragmatism wins out and you have to say "this is more trouble than it's worth".
WOW64 itself contains known bugs and incompatibilities, e.g. unless they've fixed it then any 32-bit application using GetThreadContext() is likely to break.
Yeah, I had a sig once; I got bored of it.
--Yep, I can confirm Linux Mint 14 is also running 64-bit Firefox natively:
$ file /usr/lib/firefox/firefox /usr/lib/firefox/firefox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xbecff14f9dff514573ccdae8cbeb2c9ecf119c2e, stripped
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
> There's no 64-bit Chrome, so this is a moot point. /opt/google/chrome/chrome
/opt/google/chrome/chrome: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
$ file
Micro$oft is stuck in the past. Their windows OS is tied to the PC and to an old 32bit architecture which are both going to be deprecated soon.
9 years ago
No colour or religion ever stopped the bullet from a gun
There's still a 32-bit Windows?
"We live in a global world" - Harvey Pitt, former Securities and Exchange Commission Chairman
That or someone whose boss wants a port out now before one has a chance to finish reading the entire contents of the MSDN web site.
I'm actually rather surprised at how hard it is to get specific information on the ARM64 instruction set at this point. [...]
The ARM architecture supports physical address extension (PAE) with a 40-bit (1 TiB) physical address space. On ARM, as on x86, PAE potentially allows hundreds of GB of RAM but only 2 GB per process. Under Android, applications can share a process, but different publishers' applications run in separate processes. Though PAE-intolerant drivers for desktop peripherals have forced Microsoft to switch off PAE for desktop Windows, 32-bit versions of Windows Server support PAE on x86, as does Linux both on x86 and on ARM. So you might see Android devices using PAE long before they go 64-bit.