So che ci sono molte differenze tra OSX e Linux, ma cosa li rende così totalmente diversi da renderli fondamentalmente incompatibili?
Risposta accettata:
L'intero ABI è diverso, non solo il formato binario (Mach-O contro ELF) come menzionato da sepp2k.
Ad esempio, mentre sia Linux che Darwin/XNU (il kernel di OS X) usano sc su PowerPC e int 0x80 /sysenter /syscall su x86 per l'immissione di syscall, da lì in poi non c'è molto più in comune.
Darwin indirizza i numeri di syscall negativi al microkernel Mach e i numeri di syscall positivi al kernel monolitico BSD — vedere xnu/osfmk/mach/syscall_sw.h e xnu/bsd/kern/syscalls.master. I numeri di syscall di Linux variano in base all'architettura:vedere 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 numeri di syscall, argomenti di syscall e persino quali le chiamate di sistema esistenti sono diverse.
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 l'intera libreria Cocoa Objective-C, i programmi GUI su OS X parlano a WindowServer tramite le porte Mach, mentre su Linux, i programmi GUI di solito parlano con il server X tramite socket di dominio UNIX utilizzando il protocollo X11. Naturalmente ci sono delle eccezioni; puoi eseguire X su Darwin e puoi bypassare X su Linux, ma le applicazioni OS X sicuramente non parlano di X.
Come Wine, se qualcuno ci mette il lavoro in
- Implementazione di un caricatore binario per Mach-O
- intercettare ogni syscall XNU e convertirlo in syscall Linux appropriati
- scrittura di sostituzioni per librerie OS X come CoreFoundation secondo necessità
- scrittura di 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 al primo elemento, 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 l'esecuzione di binari da altri UNIX come HP-UX e Tru64, e il progetto Glendix mira a portare la compatibilità di Plan 9 a Linux.)
Qualcuno ha sforzati di implementare un caricatore binario Mach-O e un traduttore API per Linux!
shinh/maloader – GitHub adotta l'approccio simile a Wine per caricare il binario e intrappolare/tradurre tutte le chiamate alla libreria nello spazio utente. Ignora completamente le syscall e tutte le librerie relative alla grafica, ma è sufficiente per far funzionare molti programmi console.
Correlati:Linux – Come visualizzare il messaggio di benvenuto in unix??Darling si basa su maloader, aggiungendo librerie e altri bit di runtime di supporto.