LWN: 在 Linux 上运行 macOS 程序

Darling: macOS compatibility for Linux

July 30, 2019

本文由 Sean Kerner 撰写

目前有个名叫Darling的项目活跃度不断提升，这个项目是希望能在Linux上提供一个针对macOS软件的translation layer（翻译层），有点类似Wine这个项目所做的工作。Darling比起Wine来说，成熟度差得尚远，因此开发者们现在仍在尽力能增加更多功能，使得此项目在今后的某一天能够对更多用户提供帮助。

7月23日的时候，Darling发布了2019年第二季度的进展报告，整体介绍了项目当前的状况和进展：“我们很激动的看到，在2019年第二季度（四月一日至六月三十日）期间，社区的活跃度大大提高，有众多的pull request出现，低至底层汇编、高至例如AppKit这样的上层架构，都有不少bug fix贡献。”

根据项目官方网站，项目名“Darling”是"Darwin”和“Linux”的组合而成的。Darwin是macOS基金会的开源工作，主要提供了macOS底层的Unix层。

▎Licensing

Darling使用GPLv3 license，根据项目主页上的描述，这跟Apple的End User License Agreement （EULA，终端用户协议）并不冲突，因为它仅仅使用了Darwin里面以开源软件形式发布的一部分。不过Darwin本身是按照“Apple Public Source License (APSL)”协议发布的，这虽然也是一个free-software license，不过按FSF所说，它跟GPL并不相容。

在7月25日BountySource的一个issue的讨论里，Richard Yao建议Darling改换为另一个license，例如LGPLv2.1，他认为这个应该跟APSL是相容的。不过Darlin的贡献者Lubos Dolezel有不同看法，他认为可以把GPL的代码同其他不同license的代码一起分发：“如果你看看大多数的Linux分发版，你会发现一些软件包是采用互不相容的license的。这并不是说他们就不能在同一个RPM/DEB的仓库内共存了，也不是说你不能写个bash脚本来调用两种license世界的可执行程序。Darling不是仅仅一个application，而是类似于macOS的一个发行版。”

不清楚这个理由是否也能延伸到kernel module部分，因为kernel module都是采用GPL协议，但是根据Yao所说，包含了不少的XNU（Darwin kernel）代码，都是采用了APSL协议的。

▍Beyond Darwin

除了Darwin，还有一些工具和函数库也用在了Darling中，包含Cocotron（一个Cocoa的开源实现，Cocoa是Apple的桌面应用程序API）。在一次采访中，Darling的贡献者Andrew Hyatt解释说，这个项目可以被认为是由很多不同组件组合在一起而来的。所有在https://opensource.apple.com 上的可能可以利用的项目都被取来放在Darling项目中了：“一般是各种命令行工具，不过也确实包含一些系统库、框架等，例如Security和libsystem。像AppKit这些，代码就跟Apple无关了。我们的AppKit和基础代码都是基于Cocotron的源代码。自从我们fork出来之后，最新的cocotron代码又有了不少改善，我们也在逐步把这些改进拿到Darwin项目里来。我觉得目前我们所碰到的问题里面，最主要问题还是功能不全，而顾不上是否跟其他开源代码保持同步。”

Appkit是一个框架，包含了很多库函数和对象，能用来创建application的用户界面元素。Darling已经引入了很多其他的框架，其中不少都是上个季度由贡献者James Urquhart引入的。季度报告里面指出Urquhart的pull request针对这许多框架也引入了更多代码stub。Urquhart在一次采访中也解释了，这些stub都是一些API函数的实现，有了它们，使用了这些API的application才能正常加载起来：“很多stub函数都仅仅是加了这个stub，没做任何具体功能实现，因此没法保证程序可以运行正确。所以这些stub函数仅仅是将来完整实现API的一个踏脚石。”

Urquhart贡献的framework stub包含AGL，这是用来创建和管理OpenGL rendering context（渲染上下文）的。此外他还贡献了很多stub函数，包括Carbon相关框架的（这是C语言的API，用来对Mac OS 8和9的应用程序确保能在Mac OS X上正常运行的），还有跟Carbon配合的Core Service framework，用来提供identity等服务的。还有ApplicationService，用来给Carbon增加更多功能。

Urquhart补充说，通常来说，他贡献的代码的测试标准是能够让legacy application能在一定程度上运行起来，但是不包含GUI。上面提到的这些框架里增加的stub，目的就是让相关application能够被成功加载。

Darling的报告里面还提到了MacOS内部的框架嵌套带来的问题：MacOS上的一些框架，看起来好像是一个框架，其实底层是多个子框架，然后链接在一起，最终对外暴露成一个整体的样子。目前Darling的编译系统仍然没能支持这种框架嵌套。6月份的时候，Andrew Hyatt增加了相关的支持，因此类似Accelerate这样的系统框架就可以拥有跟macOS上相同的文件组织结构了。这是通过利用一些CMake的技巧以及细致安排系统框架的代码文件结构来实现的。

▎What can you do with Darling

Darling还是跟Wine不同，没法在Linux上运行例如Xcode IDE这样的完整macOS GUI程序。Xcode是Apple的核心开发工具的集合，用来编译macOS和iOS应用程序。Urquhart也说他还没有在任何正式工作场景下用过Darling，目前他大多数修修补补的改动只是做了一个能证明理论可行而已。

虽然全GUI的application还没法运行，不过这不代表macOS application无法运行。Hyatt解释说，如果你想做的测试是可以在纯命令行下实现的，那么很可能能正常工作起来。“过去几年我们花了很多精力解决了一些xcodebuild运行问题，希望能在命令行上编译Xcode项目代码了，我想等这个工作正式完成的时候，就会有更多的人加入Darling项目，因为这样就足够让人实现在Linux上编译iOS/macOS的app的目标了。”

Hyatt专门提到了展示了一种有趣用法的一个Darling GitHub issue。Tom Medema在问是否能运行sketchtool，这是很流行的Sketch macOS app的命令行接口。目前bug report里面能看到已经有不少进展，目前已经可以让sketchtool运行起来，打印出它的使用方法的字符串了。

Darling还有一个应用场景，就是来执行32位软件。在今年下半年会发布的macOS Catalina release里，Apple不再支持32位应用程序了。他说“对于老版本的app，我们比今后macOS有可能会拥有更好的兼容性，因为我们可以在我们API里增加更多条件判断逻辑，从而提供一个更好的兼容层”。

展望未来，Hyatt更加期望大家能提交patch来解决他们想要在Darling上用到的application的兼容性问题。他说：“现在还很难估计需要多久才能支持完整的GUI app，可能是几年，不确定，这应该取决于我们能吸引到多少位有时间有能力的贡献者进来。”

总之，还需要一些时间才能看出Darling会否是一个成功的项目，希望最终能达到像Wine那样的成功，使得大量macOS application都能在Linux上运行起来。Wine花了很多年来稳定下来，并且一直在持续开发来增加更多application的支持。对Darling来说估计也是类似的策略。可以确定的是，目前已经有一组开发者很有兴趣并且全力在想办法能让macOS application在Linux上运行起来。

LWN文章遵循CC BY-SA 4.0许可协议。

END