For Chrome, 32 bits are not enough

Google is touting its 64-bit build of Chrome for OS X, scheduled for rollout with Chrome 39 in November. Almost a whisper by comparison, though, is what will happen to the 32-bit build. Well, it's very simple: it won't exist. This is the end for the 32-bit Intel Mac as far as Google is concerned, even though those Macs can run 10.6, which Chrome, at least for the moment, still supports. Chromium might still build, but I wouldn't bet on it.

Besides the obvious -- no 32-bit browser -- there are some other knock-on effects, the most important being that 32-bit plugins won't work either. This is not a big deal presently since the major plugins have 64-bit versions now, but Google is completely removing NPAPI plugin support later this year as well. This leaves its perverse little PPAPI plugin support, which only Chrome can run, to maintain Flash compatibility using its bespoke in-browser version; Mozilla, Microsoft and Apple have all uniformly refused to support PPAPI. That's okay with Google, because soon their Native Client implementation is going to take over your desktop with Android apps anyway.

As it stands, Firefox is a fat x86 binary with 32-bit and 64-bit versions, but historically when Google has withdrawn support Mozilla has been quick to follow, and Google's decision is already being discussed on the Mozilla developer channels. Currently the only thing really forcing 32-bit support is the need for Silverlight for Mac, which doesn't exist in a 64-bit version. Since Chrome won't be supporting NPAPI plugins of any kind soon, they don't have that limitation; should Mozilla find a HTML5 workaround for sites like Netflix, or the userbase drop enough, you can confidently expect the end of 32-bit support on OS X from Firefox as well.

This is important for us in two respects: we rely on a lot of 10.6 code still, and a 64-bit only build clears the way to end 10.6 support; and we are a 32-bit hybrid Carbon/Cocoa application. The only 64-bit Power Mac is the G5, but even if I limited TenFourFox to the G5 systems exclusively (which I won't do, because at a minimum I myself use the 7450 build also), it still wouldn't work because there is no 64-bit Carbon and 10.4's 64-bit Cocoa support is incomplete. As long as 32-bit builds persist, 10.6 support is likely to remain as well, because they serve no purpose on 10.7+. Once they disappear, I predict Mozilla will drop both 10.6 and 10.7 simultaneously and support only 10.8+. (Remember, Firefox already can no longer be built on 10.6, even though it will still run on it.) We could probably still make much of the cross-platform code work on 32-bit PowerPC because the Linux and Windows tier-1 builds still support 32-bit, at least for the time being, but the OS X-specific portions would become much harder to work with.

On that note, due to my dissatisfaction I've decided to scotch the 33 release and jump to working on 34. (If you want the changesets to build your own to play with, you can get them from the unstable folder on SourceForge. Please note that they are against 33-aurora, which is now 33-beta, so you should expect some merging to be required.) For now, I'm just concentrating on getting to 38, and secondarily on completing the MIPS JIT conversion to PowerPC; 34 is currently crippled by a severe bug on systems without hardware acceleration, but this is biting Mozilla as well, so it is virtually certain they will fix it shortly. 38 is kind of a nice milestone because by the end of 38ESR support, even the last quad G5 to roll off the assembly line will have received a full 10 years of support, from 2006 to 2016. I'd really like to make that, at least, and pick up the important HTML5 and ECMA6 features that are being added such as <picture>.

In other news, I picked up an Apple Workgroup Server 9150 and restored it this weekend. I'm sort of developing a hyperspecialized interest in Apple server-grade hardware, such as it existed, particularly the truly unique Apple Network Servers; while I don't really have much interest in the Workgroup Servers in general because they were rebadged workstation Macs with occasionally different storage loadouts, the WGS 9150 is a legitimately odd chimera of the Quadra 950/Apple Workgroup Server 95 and the Power Macintosh 8100 with some strange attributes of its own. In its prototype form as Green Giant, it was also the testbed for Apple's brief and sorrowful flirtation with NetWare (the so-called "Wormhole" project); it went over so badly with testers that Apple ended up developing Shiner in its place, which became the ANS, and the Green Giant prototype was recycled into the 9150 with MacOS. After stripping it down, cleaning its profoundly grimy contents, applying a bit of steel wool and gentle care to get the yellowing and deep marks out of the plastic, and then replacing the CD-ROM, adding another hard disk and recabling it, it is now sitting next to the G5 quietly installing MkLinux. Why MkLinux, you ask? Because it's period-appropriate, it probably doesn't suck on the 601, Apple actually supported it, and I want to compare it to Rhapsody. Watch for an "ANFSCD" on it in the near future.

Finally, I am concerned that SeaMonkey PPC has halted updates; I haven't seen anything since May of this year. Our Tenfourbird builder from the Land of the Rising Sun has been keeping pace, but SeaMonkey PPC is based on its own code, and it's possible he hasn't been able to keep it working. Hopefully that's not the case, since the looming end of the original WebKit1 will also limit Leopard WebKit users, though I know Tobias will continue to work on fixes and improvements. We need more and better browser support for OS X/ppc, not less.