Cosa rende i programmi OSX non eseguibili su Linux?

So che ci sono molte differenze tra OSX e Linux, ma cosa le rende così totalmente diverse, che le rendono fondamentalmente incompatibili?

L'intera ABI è diversa, non solo il formato binario (Mach-O contro ELF) come menzionato sepp2k.

Ad esempio, mentre sia Linux che Darwin / XNU (il kernel di OS X) usano scsu PowerPC e int 0x80/ sysenter/ syscallsu x86 per la voce syscall, da lì in poi non c'è molto più in comune.

Darwin dirige numeri di syscall negativi nel microkernel Mach e numeri di syscall positivi nel kernel monolitico BSD - vedi xnu / osfmk / mach / syscall_sw.h e xnu / bsd / kern / syscalls.master . I numeri di syscall di Linux variano in base all'architettura - vedi linux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h e linux / arch / x86 / include / asm / unistd_64.h - ma sono tutti non negativi. Quindi ovviamente i numeri di syscall, gli argomenti di syscall e persino quali syscall esistono sono diversi.

Anche le librerie di runtime C standard sono diverse; Darwin eredita principalmente la libc di FreeBSD, mentre Linux usa tipicamente glibc (ma ci sono alternative, come eglibc e dietlibc e uclibc e Bionic).

Per non parlare del fatto che l'intero stack grafico è diverso; ignorando le intere librerie Cocoa Objective-C, i programmi GUI su OS X parlano con WindowServer su porte Mach, mentre su Linux i programmi GUI di solito parlano con il server X su socket di dominio UNIX usando il protocollo X11. Naturalmente ci sono eccezioni; puoi eseguire X su Darwin e puoi bypassare X su Linux, ma le applicazioni OS X sicuramente non parlano X.

Come il vino, se qualcuno ci mette dentro il lavoro

• implementando un caricatore binario per Mach-O
• intrappolando ogni syscall XNU e convertendolo in syscall Linux appropriati
• scrivere sostituzioni per librerie OS X come CoreFoundation, se necessario
• scrivere sostituzioni per servizi OS X come WindowServer secondo necessità

quindi potrebbe essere possibile eseguire un programma OS X "nativamente" su Linux. Anni fa, Kyle Moffet ha lavorato sul primo oggetto, creando un prototipo binfmt_mach-o per Linux, ma non è mai stato completato e non conosco altri progetti simili.

(In teoria questo è del tutto possibile e sforzi simili sono stati fatti molte volte; oltre a Wine, Linux stesso ha il supporto per eseguire binari da altri UNIX come HP-UX e Tru64, e il progetto Glendix mira a portare la compatibilità con Plan 9 Linux.)

Qualcuno si è impegnato a implementare un caricatore binario Mach-O e un traduttore API per Linux!

shinh / maloader - GitHub adotta l'approccio simile al vino di caricare il binario e intrappolare / tradurre tutte le chiamate della libreria nello spazio utente. Ignora completamente syscalls e tutte le librerie relative alla grafica, ma è sufficiente per far funzionare molti programmi console.

Il tesoro si basa su Maloader, aggiungendo librerie e altri bit di runtime di supporto.

Perché le applicazioni OSX non funzioneranno in modo nativo su Linux:

Innanzitutto OSX utilizza un formato binario diverso da Linux, quindi Linux non può eseguire binari compilati per OSX (allo stesso modo in cui non può eseguire binari compilati per Windows o BSD).

In secondo luogo, se stai parlando di applicazioni GUI, il toolkit della GUI di Apple Cocoa a) è disponibile solo per OSX eb) non funziona su X11.

Perché non esiste un equivalente di wine per le applicazioni OSX:

È stato necessario molto lavoro prima che il vino fosse utilizzabile anche a metà. Dal momento che non c'è molta domanda per un equivalente OSX, nessuno ha ancora investito la stessa quantità di sforzi in un tale progetto.

Il motivo più importante per cui le app OS X non verranno eseguite su Linux è perché tali sistemi operativi utilizzavano syscall diversi.

Alcune risposte precedenti menzionavano le biblioteche, ma in genere non è così: Core Foundation è in gran parte aperta da Apple con il nome CFLite e facilmente trasportabile su qualsiasi piattaforma (la versione Windows di iTunes si trova effettivamente in cima a una porta Windows di Core Foundation, e con alcune modifiche al compilatore, puoi creare direttamente CFLite usando clang su una distribuzione Linux) e ci sono anche sforzi open source per il porting dell'ambiente Objective-C, principalmente Foundation e AppKit su Linux, in particolare GNUstep, un'implementazione GNU di OpenStep, che risaliva a prima del Cocoa di Apple (iniziato quando c'era ancora la società NeXT Computer.)

Se qualcuno è determinato, può progettare un caricatore in grado di catturare ogni syscall Mach-O e tradurlo nella corrispondente syscall Linux, nonché di collegare dinamicamente quelle "controparti" della libreria open source al binario con la traduzione ABI appropriata.

E solo per tua informazione, se riesci a ottenere il codice sorgente dell'applicazione Mach-O, puoi considerare di portarlo e potrebbe rivelarsi molto semplice. Ad esempio, l'app TextEdit in bundle con OS X 10.6 può essere ricompilata direttamente con GNUstep dopo aver rimosso alcune righe di codice CF (non critico) e quindi immediatamente disponibile sotto Linux (per non parlare del TextEdit fornito con GNUstep era in realtà un ricompilazione diretta dell'app TextEdit da NeXTSTEP, il precursore di OS X, pur mantenendo l'etichetta "© 1995 NeXT"). TextEdit è sotto licenza BSD.

L'8 dicembre 2012 è stato lanciato un nuovo progetto: tesoro.

http://www.darlinghq.org/