是什么导致 OSX 程序无法在 Linux 上运行？

Question 1

整体ABI是不同的，不仅仅是如 sepp2k 提到的二进制格式（Mach-O 与 ELF）不同。

例如，虽然 Linux 和 Darwin/XNU（OS X 的内核）都sc在 PowerPC 和int 0x80/ sysenter/ syscallx86 上使用系统调用入口，但从那以后就没有太多共同点了。

Darwin 在 Mach 微内核上指示负系统调用号，在 BSD 单片内核上指示正系统调用号 — 请参阅xnu/osfmk/mach/syscall_sw.h和xnu/bsd/kern/syscalls.master。 Linux 的系统调用数量因体系结构而异 — 请参阅linux/arch/powerpc/include/asm/unistd.h,linux/arch/x86/include/asm/unistd_32.h，和linux/arch/x86/include/asm/unistd_64.h— 但都是非负的。因此显然系统调用号、系统调用参数，甚至哪个系统调用存在不同。

标准 C 运行时库也不同； Darwin 大部分继承了 FreeBSD 的 libc，而 Linux 通常使用 glibc（但也有替代方案，例如eglibc、dietlibc、uclibc 和 Bionic）。

更不用说整个图形堆栈是不同的；忽略整个 Cocoa Objective-C 库，OS X 上的 GUI 程序通过 Mach 端口与 WindowServer 通信，而在 Linux 上，GUI 程序通常使用 X11 协议通过 UNIX 域套接字与 X 服务器通信。当然，也有例外;你可以在 Darwin 上运行 X，并且可以在 Linux 上绕过 X，但 OS X 应用程序绝对不与 X 对话。

就像葡萄酒一样，如果有人把工作投入到

为 Mach-O 实现二进制加载器
捕获每个 XNU 系统调用并将其转换为适当的 Linux 系统调用
根据需要编写 CoreFoundation 等 OS X 库的替代品
根据需要编写 WindowServer 等 OS X 服务的替代品

那么在 Linux 上“本地”运行 OS X 程序是可能的。几年前，凯尔·莫菲特 (Kyle Moffet) 对第一个项目做了一些工作，创建了一个原型binfmt_mach-oLinux 上的项目，但它从未完成，据我所知没有其他类似的项目。

（理论上这是完全有可能的，并且类似的努力已经做过很多次了；除了 Wine 之外，Linux 本身还支持运行来自其他 UNIX 的二进制文件，例如 HP-UX 和 Tru64，并且格兰迪克斯项目旨在将 Plan 9 兼容性引入 Linux。）

有人有努力为 Linux 实现 Mach-O 二进制加载器和 API 转换器！

shinh/maloader - GitHub采用类似 Wine 的方法来加载二进制文件并捕获/翻译用户空间中的所有库调用。它完全忽略系统调用和所有图形相关的库，但足以让许多控制台程序运行。

亲爱的基于 maloader 构建，添加库和其他支持运行时位。

Answer

整体ABI是不同的，不仅仅是如 sepp2k 提到的二进制格式（Mach-O 与 ELF）不同。

例如，虽然 Linux 和 Darwin/XNU（OS X 的内核）都sc在 PowerPC 和int 0x80/ sysenter/ syscallx86 上使用系统调用入口，但从那以后就没有太多共同点了。

Darwin 在 Mach 微内核上指示负系统调用号，在 BSD 单片内核上指示正系统调用号 — 请参阅xnu/osfmk/mach/syscall_sw.h和xnu/bsd/kern/syscalls.master。 Linux 的系统调用数量因体系结构而异 — 请参阅linux/arch/powerpc/include/asm/unistd.h,linux/arch/x86/include/asm/unistd_32.h，和linux/arch/x86/include/asm/unistd_64.h— 但都是非负的。因此显然系统调用号、系统调用参数，甚至哪个系统调用存在不同。

标准 C 运行时库也不同； Darwin 大部分继承了 FreeBSD 的 libc，而 Linux 通常使用 glibc（但也有替代方案，例如eglibc、dietlibc、uclibc 和 Bionic）。

更不用说整个图形堆栈是不同的；忽略整个 Cocoa Objective-C 库，OS X 上的 GUI 程序通过 Mach 端口与 WindowServer 通信，而在 Linux 上，GUI 程序通常使用 X11 协议通过 UNIX 域套接字与 X 服务器通信。当然，也有例外;你可以在 Darwin 上运行 X，并且可以在 Linux 上绕过 X，但 OS X 应用程序绝对不与 X 对话。

就像葡萄酒一样，如果有人把工作投入到

为 Mach-O 实现二进制加载器
捕获每个 XNU 系统调用并将其转换为适当的 Linux 系统调用
根据需要编写 CoreFoundation 等 OS X 库的替代品
根据需要编写 WindowServer 等 OS X 服务的替代品

那么在 Linux 上“本地”运行 OS X 程序是可能的。几年前，凯尔·莫菲特 (Kyle Moffet) 对第一个项目做了一些工作，创建了一个原型binfmt_mach-oLinux 上的项目，但它从未完成，据我所知没有其他类似的项目。

（理论上这是完全有可能的，并且类似的努力已经做过很多次了；除了 Wine 之外，Linux 本身还支持运行来自其他 UNIX 的二进制文件，例如 HP-UX 和 Tru64，并且格兰迪克斯项目旨在将 Plan 9 兼容性引入 Linux。）

有人有努力为 Linux 实现 Mach-O 二进制加载器和 API 转换器！

shinh/maloader - GitHub采用类似 Wine 的方法来加载二进制文件并捕获/翻译用户空间中的所有库调用。它完全忽略系统调用和所有图形相关的库，但足以让许多控制台程序运行。

亲爱的基于 maloader 构建，添加库和其他支持运行时位。

Question 2

为什么 OSX 应用程序不能在 Linux 上本地运行：

首先，OSX 使用与 Linux 不同的二进制格式，因此 Linux 无法执行为 OSX 编译的二进制文件（就像它无法执行为 Windows 或 BSD 编译的二进制文件一样）。

其次，如果您谈论的是 GUI 应用程序，Apple 的 GUI 工具包 Cocoa a) 仅适用于 OSX，b) 不能在 X11 上运行。

为什么 OSX 应用程序没有对应的 wine：

在葡萄酒达到半可用状态之前，还需要做很多工作。由于对 OSX 等效项的需求并不多，因此还没有人在这样的项目上投入同样多的精力。

Answer

为什么 OSX 应用程序不能在 Linux 上本地运行：

首先，OSX 使用与 Linux 不同的二进制格式，因此 Linux 无法执行为 OSX 编译的二进制文件（就像它无法执行为 Windows 或 BSD 编译的二进制文件一样）。

其次，如果您谈论的是 GUI 应用程序，Apple 的 GUI 工具包 Cocoa a) 仅适用于 OSX，b) 不能在 X11 上运行。

为什么 OSX 应用程序没有对应的 wine：

在葡萄酒达到半可用状态之前，还需要做很多工作。由于对 OSX 等效项的需求并不多，因此还没有人在这样的项目上投入同样多的精力。

Question 3

OS X 应用程序无法在 Linux 上运行的最重要原因是这些操作系统使用了不同的系统调用。

之前的一些答案提到了库，但通常情况并非如此 - Core Foundation 主要由 Apple 以 CFLite 的名称开源，并且可以轻松移植到任何平台（Windows 版本的 iTunes 实际上位于 Core Foundation 的 Windows 端口之上，并且具有一些编译器调整，您可以在 Linux 发行版上使用 clang 直接制作 CFLite），并且还有将 Objective-C 环境（主要是 Foundation 和 AppKit）移植到 Linux 的开源工作，最著名的是 GNUstep，它是 OpenStep 的 GNU 实现，它于比Apple的Cocoa还要早（当NeXT Computer公司还在的时候就开始了。）

如果有人下定决心，他们可以设计一个加载程序来捕获每个 Mach-O 系统调用并将其转换为相应的 Linux 系统调用，并通过适当的 ABI 转换将这些开源库“对应部分”动态链接到二进制文件。

仅供参考，如果您可以获得 Mach-O 应用程序的源代码，您可以考虑移植它，结果可能会非常简单。例如，与 OS X 10.6 捆绑的 TextEdit 应用程序可以在删除几行（非关键）CF 代码后直接重新编译链接到 GNUstep，因此可以立即在 Linux 下使用（更不用说 GNUstep 附带的 TextEdit 实际上是一个直接重新编译来自 NeXTSTEP（也是 OS X 的前身）的 TextEdit 应用程序，甚至保留其“© 1995 NeXT”标签）。 TextEdit 受 BSD 许可。

Answer