Что делает программы OSX не работоспособными в Linux?

Я знаю, что существует много различий между OSX и Linux, но что делает их такими совершенно разными, что делает их принципиально несовместимыми?

Весь ABI отличается, а не только двоичный формат (Mach-O против ELF), как упоминалось в sepp2k.

Например, в то время как Linux и Darwin / XNU (ядро OS X) используют scв PowerPC и int 0x80/ sysenter/ syscallв x86 для входа в системный вызов, с этого момента не так много общего.

Дарвин направляет отрицательные числа системных вызовов в микроядро Маха и положительные числа системных вызовов в монолитном ядре 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 тоже отличаются; Дарвин в основном наследует libc FreeBSD, в то время как Linux обычно использует glibc (но есть альтернативы, такие как eglibc и dietlibc и uclibc и Bionic).

Не говоря уже о том, что весь графический стек отличается; игнорируя целые библиотеки Cocoa Objective-C, программы с графическим интерфейсом на OS X взаимодействуют с WindowServer через порты Mach, а в Linux программы с графическим интерфейсом обычно общаются с X-сервером через доменные сокеты UNIX с использованием протокола X11. Конечно, есть исключения; вы можете запустить X в Darwin и обойти X в Linux, но приложения OS X определенно не говорят на X.

Как вино, если кто-то положил работу в

• реализация бинарного загрузчика для Mach-O
• перехват каждого системного вызова XNU и преобразование его в соответствующие системные вызовы Linux
• написание замен для библиотек OS X, таких как CoreFoundation, по мере необходимости
• написание замен для служб OS X, таких как WindowServer, по мере необходимости

тогда можно было бы запустить программу OS X «изначально» в Linux. Несколько лет назад Кайл Моффет немного поработал над первым элементом, создав прототип binfmt_mach-o для Linux, но он так и не был завершен, и я не знаю других подобных проектов.

(Теоретически это вполне возможно, и подобные усилия были предприняты много раз; в дополнение к Wine, в самой Linux есть поддержка запуска двоичных файлов из других UNIX, таких как HP-UX и Tru64, а проект Glendix направлен на обеспечение совместимости Plan 9 с Linux) .

Кто - то уже поставил в попытке реализовать Mach-O двоичный загрузчик и API переводчик для Linux!

shinh / maloader - GitHub использует Wine-like подход к загрузке двоичного файла и перехвату / переводу всех вызовов библиотеки в пользовательском пространстве. Он полностью игнорирует системные вызовы и все графические библиотеки, но этого достаточно, чтобы заставить работать многие консольные программы.

Darling основывается на maloader, добавляя библиотеки и другие вспомогательные биты времени выполнения.

Почему приложения OSX не будут работать в Linux:

Прежде всего OSX использует бинарный формат, отличный от Linux, поэтому Linux не может выполнять двоичные файлы, скомпилированные для OSX (так же, как он не может выполнять двоичные файлы, скомпилированные для Windows или BSD).

Во-вторых, если вы говорите о приложениях с графическим интерфейсом, инструментарий Apple с графическим интерфейсом Cocoa а) доступен только для OSX и б) не работает поверх X11.

Почему нет эквивалента wine для приложений OSX:

Надо было проделать большую работу, прежде чем вино стало пригодным даже на полпути. Поскольку не существует такого большого спроса на OSX-эквивалент, никто еще не вложил столько же усилий в такой проект.

Самая важная причина, по которой приложения OS X не будут работать в Linux, заключается в том, что эти ОС использовали разные системные вызовы.

В некоторых предыдущих ответах упоминались библиотеки, но, как правило, это не так - Core Foundation в основном открыт от Apple под названием CFLite и легко переносится на любую платформу (версия iTunes для Windows фактически располагается поверх порта Windows Core Foundation, и с некоторые настройки компилятора позволяют напрямую создавать CFLite с использованием clang в дистрибутиве Linux), а также предпринимаются усилия с открытым исходным кодом для переноса среды Objective-C, в основном Foundation и AppKit, на Linux, в частности GNUstep, GNU-реализацию OpenStep, датированную раньше, чем Apple, какао (началось, когда еще была компания NeXT Computer.)

Если кто-то определен, он может спроектировать загрузчик, который будет захватывать каждый системный вызов Mach-O и переводить его в соответствующий системный вызов Linux, а также динамически связывать эти «аналоги» библиотеки с открытым исходным кодом с двоичным файлом с соответствующим переводом ABI.

И просто для вашей информации: если вы можете получить исходный код приложения Mach-O, вы можете подумать о его портировании, и это может оказаться очень простым. Например, приложение TextEdit в комплекте с OS X 10.6 можно напрямую перекомпилировать для связывания с GNUstep после удаления нескольких строк (некритического) кода CF и, таким образом, сразу доступного в Linux (не говоря уже о том, что TextEdit, поставляемый с GNUstep, фактически был прямая перекомпиляция приложения TextEdit из NeXTSTEP, также предшествующего OS X, даже с сохранением его метки «© 1995 NeXT»). TextEdit находится под лицензией BSD.

8 декабря 2012 года был запущен новый проект - Дорогая.

http://www.darlinghq.org/