O que torna os programas OSX não executáveis ​​no Linux?

Eu sei que existem muitas diferenças entre OSX e Linux, mas o que as torna tão totalmente diferentes, que as torna fundamentalmente incompatíveis?

A ABI inteira é diferente, não apenas o formato binário (Mach-O versus ELF), como mencionado no sepp2k.

Por exemplo, enquanto o Linux e o Darwin / XNU (o kernel do OS X) usam scno PowerPC e int 0x80/ sysenter/ syscallno x86 para entrada do syscall, não há muito mais em comum a partir daí.

Darwin direciona números de syscall negativos no microkernel Mach e números de syscall positivos no kernel monolítico do BSD - consulte xnu / osfmk / mach / syscall_sw.h e xnu / bsd / kern / syscalls.master . Números syscall do Linux variam de acordo com arquitetura - ver linux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h , e linux / arch / x86 / include / asm / unistd_64.h - mas são todos não-negativos. Então, obviamente, números syscall, argumentos syscall e até quais syscalls existem são diferentes.

As bibliotecas de tempo de execução C padrão também são diferentes; Darwin herda principalmente a libc do FreeBSD, enquanto o Linux normalmente usa glibc (mas existem alternativas, como eglibc e dietlibc e uclibc e Bionic).

Sem mencionar que toda a pilha de gráficos é diferente; ignorando todas as bibliotecas Cocoa Objective-C, os programas GUI no OS X conversam com o WindowServer pelas portas Mach, enquanto no Linux, os programas GUI geralmente conversam com o servidor X nos soquetes de domínio UNIX usando o protocolo X11. Claro que há exceções; você pode executar o X no Darwin e ignorar o X no Linux, mas os aplicativos OS X definitivamente não falam o X.

Como o vinho, se alguém colocar o trabalho em

• implementando um carregador binário para Mach-O
• interceptando cada syscall do XNU e convertendo-o em syscalls do Linux apropriados
• escrevendo substituições para bibliotecas OS X como CoreFoundation, conforme necessário
• escrevendo substituições para serviços do OS X, como o WindowServer, conforme necessário

então, é possível executar um programa OS X "nativamente" no Linux. Anos atrás, Kyle Moffet fez alguns trabalhos no primeiro item, criando um protótipo binfmt_mach-o para Linux, mas ele nunca foi concluído e não conheço outros projetos semelhantes.

(Em teoria, isso é bem possível, e esforços semelhantes foram feitos muitas vezes; além do Wine, o próprio Linux tem suporte para a execução de binários de outros UNIXes como HP-UX e Tru64, e o projeto Glendix visa trazer a compatibilidade do Plano 9 para Linux.)

Alguém se esforçou para implementar um carregador binário Mach-O e um tradutor de API para Linux!

shinh / maloader - O GitHub adota a abordagem do Wine de carregar o binário e interceptar / traduzir todas as chamadas de biblioteca no espaço do usuário. Ele ignora completamente os syscalls e todas as bibliotecas relacionadas a gráficos, mas é suficiente para fazer com que muitos programas de console funcionem.

O Darling se baseia no maloader, adicionando bibliotecas e outros bits de tempo de execução de suporte.

Por que aplicativos OSX não são executados nativamente no linux:

Antes de tudo, o OSX usa um formato binário diferente do Linux, portanto, o Linux não pode executar binários compilados para OSX (da mesma forma que não pode executar binários compilados para Windows ou BSD).

Segundo, se você está falando sobre aplicativos GUI, o kit de ferramentas GUI da Apple, Cocoa a) está disponível apenas para OSX eb) não é executado no X11.

Por que não há equivalente de vinho para aplicativos OSX:

Muito trabalho tinha que ser feito antes que o vinho fosse usado pela metade. Como não há tanta demanda por um equivalente OSX, ninguém investiu a mesma quantidade de esforço em um projeto ainda.

A razão mais importante pela qual os aplicativos OS X não serão executados no Linux é porque esses sistemas operacionais usavam syscalls diferentes.

Algumas respostas anteriores mencionaram bibliotecas, mas esse geralmente não é o caso - o Core Foundation é amplamente disponibilizado pela Apple sob o nome CFLite e é facilmente transportável para qualquer plataforma (a versão Windows do iTunes fica na parte superior de uma porta Windows do Core Foundation e com alguns ajustes do compilador, você pode criar diretamente o CFLite usando clang em uma distribuição Linux) e também existem esforços de código aberto para portar o ambiente Objective-C, principalmente Foundation e AppKit para Linux, principalmente o GNUstep, uma implementação GNU do OpenStep, datada de antes do cacau da Apple (começou quando ainda havia a empresa NeXT Computer.)

Se alguém for determinado, eles podem projetar um carregador que irá capturar todos os syscall do Mach-O e convertê-lo no syscall do Linux correspondente, além de vincular dinamicamente esses "equivalentes" da biblioteca de código aberto ao binário com a tradução ABI apropriada.

E apenas para sua informação, se você pode obter o código-fonte do aplicativo Mach-O, considere portá-lo e pode ser muito simples. Por exemplo, o aplicativo TextEdit incluído no OS X 10.6 pode ser recompilado diretamente, vinculando-se ao GNUstep após remover algumas linhas do código CF (não crítico) e, portanto, imediatamente disponível no Linux (sem mencionar que o TextEdit enviado com o GNUstep era realmente um recompilação direta do aplicativo TextEdit da NeXTSTEP, o precursor do OS X também, mantendo o rótulo "© 1995 NeXT"). TextEdit está sob licença BSD.

Em 8 de dezembro de 2012, foi lançado um novo projeto - Darling.

http://www.darlinghq.org/