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

Question

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

    

Answer 1

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

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

Darwin direciona números syscall negativos no microkernel Mach e números syscall positivos no kernel monolítico BSD - veja xnu / osfmk / mach / syscall_sw.h e xnu / bsd / kern / syscalls.master . Os números de syscall do Linux variam de acordo com a arquitetura - veja 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, os números syscall, os argumentos syscall e até mesmo quais os syscalls existem são diferentes.

As bibliotecas de tempo de execução padrão C também são diferentes; Na maioria das vezes, o Darwin herda a libc do FreeBSD, enquanto o Linux normalmente usa o 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 Objective-C do Cocoa, os programas GUI no OS X conversam com o WindowServer sobre as portas do Mach, enquanto no Linux, os programas GUI geralmente conversam com o servidor X sobre os soquetes do domínio UNIX usando o protocolo X11. Claro que existem exceções; você pode executar o X no Darwin, e você pode ignorar o X no Linux, mas os aplicativos do OS X definitivamente não falam sobre o X.

Como Wine, se alguém colocar o trabalho em

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

então é possível executar um programa OS X "nativamente" no Linux. Anos atrás, Kyle Moffet fez algum trabalho no primeiro item, criando um protótipo binfmt_mach-o para Linux, mas nunca foi concluído e não conheço nenhum outro projeto semelhante.

(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 executar binários de outros UNIXs como HP-UX e Tru64, e o O projeto Glendix visa trazer a compatibilidade do Plan 9 para o Linux.)

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

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

O

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

    

Answer 2

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

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

Em segundo lugar, se você está falando sobre aplicações GUI, o kit de ferramentas GUI da Apple, Cocoa a) está disponível apenas para o OSX e b) não é executado sobre o X11.

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

Muito trabalho teve que ser feito antes que o vinho estivesse na metade do caminho. Como não há tanta demanda para um equivalente da OSX, ninguém investiu a mesma quantidade de esforço em um projeto como esse ainda.

    

Answer 3

A razão mais importante pela qual os aplicativos do OS X não serão executados no Linux é porque esses SOs usaram diferentes syscalls.

Algumas respostas anteriores mencionaram bibliotecas, mas isso geralmente não é o caso - a Core Foundation é amplamente aberta pela Apple sob o nome CFLite e prontamente portável para qualquer plataforma (a versão Windows do iTunes fica no topo de uma porta Windows da Core Foundation e com alguns ajustes do compilador, você pode fazer diretamente o CFLite usando o clang em uma distribuição Linux) e também existem esforços open-source para portar o ambiente Objective-C, principalmente Foundation e AppKit para Linux, mais notavelmente o GNUstep, uma implementação GNU do OpenStep , que datava mais cedo do que o Apple's Cocoa (começou quando ainda havia a empresa NeXT Computer).

Se alguém for determinado, ele pode projetar um carregador que irá capturar cada syscall do Mach-O e traduzi-lo para o syscall do Linux correspondente, bem como vincular dinamicamente os "contrapartes" da biblioteca de código aberto ao binário com tradução apropriada do ABI .

E apenas para sua informação, se você pode obter o código-fonte do aplicativo Mach-O, você pode considerá-lo e pode ser muito simples. Como exemplo, o aplicativo TextEdit empacotado com o OS X 10.6 pode ser diretamente recompilado ligando-se ao GNUstep depois de extrair algumas linhas do código CF (não crítico) e, assim, imediatamente disponível no Linux (sem mencionar que o TextEdit enviado com o GNUstep era na verdade recompilação direta do aplicativo TextEdit do NeXTSTEP, o precursor do OS X, mantendo até mesmo seu rótulo "© 1995 NeXT". TextEdit está sob licença BSD.

    

Answer 4

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

link