ti-enxame.com

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?

40
Falmarri

O todo ABI é 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 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 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 . Os números de syscall do Linux variam de acordo com a arquitetura - consulte 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 do syscall, os argumentos do syscall e até os quais existem syscalls 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 trabalhou 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 levar a compatibilidade do Plano 9 ao Linux.)


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

shinh/maloader - 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.

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

56
ephemient

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 teve que ser feito antes que o vinho estivesse na metade do uso. Como não há tanta demanda por um equivalente OSX, ninguém investiu a mesma quantidade de esforço nesse projeto ainda.

20
sepp2k

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 por Apple sob o nome CFLite e é facilmente transportável para qualquer plataforma) (a versão do iTunes para Windows fica na parte superior da uma porta Windows do Core Foundation e, com alguns ajustes do compilador, você pode criar CFLite diretamente 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 antes do Cocoa 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, bem como 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 (para não 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.

5
Maxthon Chan

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

http://www.darlinghq.org/

1
Tata_Kazika