TenFourFox FPR25 available

TenFourFox Feature Parity Release 25 final is now available for testing (downloads, hashes, release notes). There are no additional changes other than outstanding security updates. Assuming all goes well, it will go live on Monday afternoon/evening Pacific time.

For FPR26 there will be one additional change to DOM workers and I'm looking at some problem sites to see if there are some easy fixes. Still, the big issues continue to be the big issues and we'll just have to do things like the AppleScript workarounds to deal with them better in future. I'd like to see more people experimenting with AppleScript, too -- we have a whole page of documentation devoted to it and some examples which you can download if you don't want to type them in.

Meantime, did you know Apple had LocalTalk cards for the PC?

TenFourFox FPR25b1 available

TenFourFox Feature Parity Release 25 beta 1 is now available (downloads, hashes, release notes). Raphaël traced the the Twitch JavaScript crash we wallpapered over in FPR24 back to an issue with DOM workers not having sufficient memory allocated, so we widened that out. There still seems to be an endian issue Twitch is triggering, because it needs a huge amount of memory for its worker to finish and then can't spawn another thread because there's not enough memory to (but it reportedly works on Intel TenFourFox, so it's something specific about PowerPC). But hey! No crashes!

Raphaël gets a second gold star for noticing that the gcc runtime we include with every copy of TenFourFox (because we build with a later compiler) is not itself optimized for the underlying platform, because MacPorts simply builds it for ppc rather than one of the specific subtypes. So he built four sets of runtime libraries for each platform and I've integrated it into the build system so that each optimized build now uses a C/C++ runtime tuned for that specific processor family (the debug build is still built for generic ppc so it runs on anything). This is not as big an improvement as you might think because JavaScript performance is almost overwhelmingly dominated by the JIT, and as I mentioned, JavaScript is one of the few areas TenFourFox has tuned and tested to hell. But other things such as DOM, graphics, layout and such do show some benefit, and scripts that spend more time in the interpreter than the JIT (primarily short one-offs) do so as well. There are no changes in the gcc runtime otherwise and it's still the same code, just built with better flags.

This release also includes additional hosts for adblock and additional fonts for the ATSUI font blocklist, and will have the usual security updates as well. It will come out parallel with Firefox 68.11 on or about July 28.

TenFourFox FPR24 available

TenFourFox Feature Parity Release 24 final is now available for testing (downloads, hashes, release notes). There are no additional changes other than outstanding security updates. Assuming all goes well, it will go live on Monday afternoon/evening Pacific time.

I don't have a clear direction for FPR25. As I said, a lot of the low hanging fruit is already picked, and some of the bigger projects are probably too big for a single developer trying to keep up with monthly releases (and do not lend themselves well to progressive implementation). I'll do some pondering in the meantime.

The Super Duper Universal Binary

A question I got repeatedly the last couple days was, now that AARM (Apple ARM) is a thing, is the ultimate ARM-Intel-PowerPC Universal Binary possible? You bet it is! In fact, Apple already documents that you could have a five-way binary, i.e., ARM64, 32-bit PowerPC, 64-bit PowerPC, i386 and x86_64. Just build them separately and lipo them together.

But it's actually more amazing than that because you can have multiple subtypes. Besides generic PPC or PPC64, you can have binaries that run specifically on the G3 (ppc750), G4 (ppc7400 or ppc7450) or G5 (ppc970). The G5 subtype in particular can be 32-bit or 64-bit. I know this is possible because LAMEVMX is already a three-headed binary that selects the non-SIMD G3, AltiVec G4 or special superduper AltiVec G5 version at runtime from a single file. The main reason I don't do this in TenFourFox is that the resulting executable would be ginormous (as in over 500MB in size).

But ARM has an even more dizzying array of subtypes, at least nine, and the Apple ARM in the new AARM Macs will probably be a special subtype of its own. This means that theoretically a Super Duper Universal Binary ("SDUB") could have all of the following:

• ppc750
• ppc7400
• ppc7450
• ppc970 (this would work for both 32-bit and 64-bit on the G5)
• i386
• x86_64
• x86_64h (i.e., Haswell, here's an example, thanks Markus Stange for pointing this out)
• armv4t
• armv5
• armv6
• armv6m
• armv7
• armv7em
• armv7k
• armv7m
• armv7s
• whatever AARM Macs turn out to be

That's potentially a 17-way binary. The best part is that each individual subpart can link against a different Mac OS X/macOS SDK, so the PowerPC subportions could be linked against 10.4, the i386 subportion against anything from 10.4 through 10.6, the x86_64 subportion against 10.4 through 10.15 (+/- the Haswell subtype), the various weirdo ARM subportions against whatever macOS SDK is relevant to the corresponding iOS version, and the AARM Mac-specific subportion against 11.0. It may be necessary to lipo it together in multiple stages using multiple machines or Xcodes depending on which subtypes are known to that platform, but after you do that, code-sign and/or notarize you should have the ultimate Super Duper Universal Binary able to run on any of these systems. Now, there's a challenge for someone. I look forward to one of those Developer Transition Kits getting put to good use here.

macOS Big Unsure

Finally, Mac OS X goes to 11 with macOS Big Sur. In keeping with Apple's name selection from wildly inappropriate California landmarks, in just three versions you can go from a dusty, hostile desert to an expensive, cramped island and now steep cliffs with rugged beauty as your car goes off a substandard bridge into the Pacific Ocean.

But there's no doubt that Apple's upcoming move to ARM across all its platforms, or at least Apple's version of ARM (let's call it AARM), makes supreme business sense. And ARM being the most common RISC-descended architecture on the planet right now, it's a bittersweet moment for us Power Mac luddites (the other white meat) to see the Reality Distortion Field reject, embrace and then reject x86 once again.

Will AARM benefit Apple? You bet it will. Apple still lives in the shadow of Steve Jobs who always wanted the Mac to be an appliance, and now that Apple controls almost all of the hardware down to the silicon, there's no reason they won't do so. There's certainly benefit to the consumer: Big Sur is going to run really well on AARM because Apple can do whatever hardware tweaks, add whatever special instructions, you name it, to make the one OS the new AARM systems will run as fast and energy-efficient as possible (ironically done with talent from P. A. Semi, who was a Power ISA licensee before Apple bought them out). In fact, it may be the only OS they'll be allowed to run, because you can bet the T2 chip will be doing more and more essential tasks as application-specific hardware adds new functionality where Moore's law has failed. But the biggest win is for Apple themselves, who are no longer hobbled by Intel or IBM's respective roadmaps, and because their hardware will be sui generis will confound any of the attempts at direct (dare I say apples to apples) performance comparisons that doomed them in the past. AARM Macs will be the best machines in their class because nothing else will be in their class.

There's the darker side, too. With things like Gatekeeper, notarization and System Integrity Protection Apple has made it clear they don't want you screwing around with their computers. But the emergence of AARM platforms means Apple doesn't have to keep having the OS itself slap your hand: now the development tools and hardware can do it as well. The possibilities for low-level enforcement of system "security" policies are pretty much limitless if you even control the design of the CPU.

I might actually pick up a low-end one to play with, since I'm sort of a man without a portable platform now that my daily driver is a POWER9 (I have a MacBook Air which I tolerate because battery life, but Mojave Forever, and I'll bet runtime on these machines will be stupendous). However, the part that's the hardest to digest is that the AARM Mac, its hardware philosophy being completely unlike its immediate predecessors, is likely to be more Mac-like than any Mac that came before it save the Compact Macs. After all, remember that Jobs always wanted the Mac to be an appliance. Now, Tim Cook's going to sell you one.

TenFourFox FPR24b1 available

TenFourFox Feature Parity Release 24 beta 1 is now available (downloads, hashes, release notes). This includes Raphaël's mitigation for Twitch frame crashes and Ken's Intel build system fixes, plus minor updates to JavaScript, DOM and layout, and fixes for sundry issues with MP3 playback (make that G4 Mac mini an Internet radio today) along with the usual security updates. Assuming all goes well, TenFourFox FPR24 will go final on or about June 29 parallel with Firefox 78.

TenFourFox FPR23 for Intel available

Ken Cunningham figured out the build issues he was having with the Intel version and has updated TenFourFox for Intel systems to FPR23, now up to date with the Power Mac version. As always, there is no support for any Intel build of TenFourFox; do not report issues to Tenderapp. You can get it from SourceForge.

Ken's patches have also been incorporated into the tree along with a workaround submitted by Raphaël Guay to deal with Twitch overflowing our JIT stack. This is probably due to something we don't support causing infinite function call recursion since with the JIT disabled it correctly just runs out of stack and stops. There is no way to increase stack further since we are strictly 32-bit builds and the stack already consumes 1GB of our 2.2-ish GB available, so we need to a) figure out why the stack overflow happens without being detected and b) temporarily disable that script until we do. It's part B that is implemented as a second blacklist which is on unless disabled, since other sites may do this, until we find a better solution to part A. This will be in FPR24 along with probably some work on MP3 compliance issues since TenFourFox gets used as a simple little Internet radio a lot more than I realized, and a few other odds and ends.

In case you missed it, I am now posting content I used to post here as "And now for something completely different" over on a new separate blog christened Old Vintage Computing Research, or my Old VCR (previous posts will remain here indefinitely). Although it will necessarily have Power Mac content, it will also cover some of my other beloved older systems all in one place. Check out properly putting your old Mac to Terminal sleep (and waking it back up again), along with screenshots of the unscreenshotable, including grabs off the biggest computer Apple ever made, the Apple Network Server. REWIND a bit and PLAY.