欢迎来到爱学习爱分享,在这里,你会找到许多有趣的技术 : )

[译] 在 Linux 上运行 macOS 程序

Linux 1691℃
点击上方蓝色“Linux News搬运工”关注我们~

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许可协议。

极度欢迎将文章分享到朋友圈
热烈欢迎转载以及基于现有协议修改再创作~

长按下面二维码关注:Linux News搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~

转载请注明:爱学习爱分享 » [译] 在 Linux 上运行 macOS 程序

喜欢 (1)or分享 (0)