将 VirtualBox 移植到新平台 - *草稿*
VirtualBox 在设计时就考虑到了可移植性，并且可移植性问题一旦发现就会得到解决。话虽如此，要在新平台上启用大部分功能仍然需要相当多的工作。所需的工作量会因新平台与 VirtualBox 已移植的平台差异程度而有所不同。例如，macOS X 在对象格式、链接器/汇编器、用户/内核地址空间布局以及内核方面都与 Linux/GNU 和 Windows 不同，这意味着需要大量工作。另一方面，以 FreeBSD 为例，唯一的主要区别是内核，因此将 VirtualBox 移植到 FreeBSD 应该比移植到 macOS X 轻松得多。
步骤 1 - 核心先决条件
这些是
- kBuild: http://svn.netlabs.org/kbuild
有关引导说明，请参阅 http://svn.netlabs.org/kbuild/wiki/Bootstrapping。
如果遇到问题，请在 irc://irc.freenode.net/vbox-dev 上询问 bird。 - bcc (Bruce Evans C 编译器) 和来自 dev86 包的 as86: http://www.cix.co.uk/~mayday/
- IASL (Intel ACPI 编译器): http://www.intel.com/technology/iapc/acpi/downloads.htm
- YASM 或 NASM (汇编器)。建议从 SVN/CVS 构建最新代码。
- 最新版 SDL: http://www.libsdl.org
步骤 2 - 开始构建
- 运行 ./configure。我建议使用 --disable-xpcom 开关运行 ./configure，除非您拥有它检查的所有 xpcom 相关项。在尝试之前，您应该在编辑器中打开 ./configure 并更改 check_environment 函数以正确识别您的操作系统。您可能还想放弃某些检查（例如 libuuid 检查），以类似于 Darwin（即 macOS X）的方式进行。
- 为您的操作系统设置 Config.kmk。这意味着找到最接近的现有移植版本，并查找该平台在 Config.kmk 中的特定设置。（顺便说一句，查看“跳过部分”一节，您可能希望像 l4、darwin 或 os2 那样跳过尚未移植的部分。）
待办：在此处添加更多细节！ - 完成最初的 Config.kmk 工作后，尝试在命令行上运行 kmk，然后开始修复构建中断。第一轮中断将发生在 BLDPROGS 阶段，这些的 kBuild 模板通常是 VBOXBLDPROG，它位于 ./Config.kmk 的末尾附近。
- 在某个时候，您会遇到由于头文件中的 #errors 导致的构建中断，这些通常是需要移植的提示。其中大部分位于 include/iprt/ 目录中，并且可能在构建 src/VBox/Runtime 时发生。Runtime，即 IPRT，是操作系统抽象（I/O、内存等）、编译器抽象（返回地址、预测、内联函数、符号导出/导入等）和一些通用构造（AVL 树、md5、压缩、字符串操作等）的混合体。再次查看与您最接近的平台，看看它有什么特殊之处。从 Makefile 开始，然后查看头文件和实现。
- 在 Runtime 中的库构建成功后，下一个问题将是 src/VBox/HostDrivers/Support。这是 VBoxDrv.sys / vboxdrv.ko / VBoxDrv.kext 代码当前所在的位置。在移植的早期阶段，我们不关心内核模式/驱动程序/扩展/或其他什么（以及它与外部的接口），只关心 SUPDRVIOC.h 中的 ioctl 值是否有效。为新平台创建一个子目录，并将现有的 SUPLib-xxxx.cpp 文件复制到其中。精简此 SUPLib-xxxx.cpp 文件，使其能够构建，但对于需要内核服务的部分，则直接失败。
- 在后续的开发中会有更多失败点，这时查看其他平台如何处理应该会有帮助。我们会根据收到的问题整理一份列表。
- 在 etherboot 中，打开 Makefile.kmk 并搜索 win.x86。如果 etherboot 无法构建，请将您的 os.arch 添加到该列表中。
- 在重编译器中，暂时禁用它，并先构建所有其他部分。当您重新处理它时，如果遇到麻烦，请查阅平台上任何现有的 qemu 移植。
- ...
步骤 3 - 使 VBoxBFE 工作
我们现在正朝着第一个重要的里程碑迈进，那就是让某些东西运行起来（尽管会非常慢）。但是，此时可能会缺少一些东西，所以我们必须耍一些花招才能得到结果。
- 由于还没有内核驱动，您必须设置一个环境变量来告诉 src/VBox/HostDrivers/Support/SUPLib.cpp 模拟内核驱动。
export VBOX_SUPLIB_FAKE=fake
- 如果平台具有未知对象/映像格式（COFF、AOUT 和 OMF 是我们尚未支持的少数几种主要格式），您将不得不编辑 src/VBox/PDMLdr.cpp，以确保
PDMLDR_FAKE_MODE已#defined。
顺便说一句，在继续之前，您可能还需要告诉您的动态链接器动态库的位置（它们就在您当前所在的位置）。
现在进入 ./out/youros.yourarch/debug/bin/（或 .../release/bin，取决于 BUILD_TYPE 环境变量）。现在建议尝试运行 ./testcase/ 中的测试用例，也许还有一些 ./tst* 程序。最好在 irc://irc.freenode.net/vbox-dev 上询问特定测试用例失败的原因，直到我们整理出例外列表。您可能还会获得有关以下方面的有用提示：
（我们将尝试根据反馈在此处整理一份例外列表）。如果您是急性子，当然可以跳过测试用例，并在运行 VBoxBFE 时遇到问题时再进行调试。
表演时间（或更可能的是真正开始调试它的时候，因此需要 gdb）
gdb --args ./VBoxBFE -m 4
一旦您看到 BIOS 标志和随后的 BIOS 引导错误，您应该下载一个简单的 Linux/GNU ISO 镜像，如 DSL (Damn Small Linux) 并尝试一下。
gdb --args ./VBoxBFE -m 128 -boot d -cdrom ./DSL.iso
对于 NAT 网络，在命令行中添加 -natdev1 080286000042。
后续步骤
既然基础部分已经构建并运行，如果恰好有更多人有兴趣提供帮助，剩余部分可以并行进行。这些部分是：
- 内核组件。
- XPCOM API (主)。完成后，除了 VBoxBFE 之外的所有前端 (src/VBox/Frontends) 都可以并行进行。
- 主机设备集成：DVD/CD-ROM、软盘、TAP、ACPI、USB（仅内部），等等。
内核组件
待办。
XPCOM
待办。
设备
待办。
