Qu'est-ce qui rend les programmes OSX non exécutables sous Linux?

Je sais qu'il existe de nombreuses différences entre OSX et Linux, mais qu'est-ce qui les rend si totalement différentes, ce qui les rend fondamentalement incompatibles?

L'ensemble du ABI est différent, pas seulement le format binaire (Mach-O versus ELF) comme mentionné par sepp2k.

Par exemple, alors que Linux et Darwin / XNU (le noyau d’OS X) utilisent sctous les deux l’entrée syscall sur PowerPC et int 0x80/ sysenter/ syscallsur 86, il n’ya pas grand-chose de commun à partir de là.

Darwin dirige les numéros d’appel système négatifs vers le micro-noyau de Mach et les numéros d’appel système positifs vers le noyau monolithique BSD - voir xnu / osfmk / mach / syscall_sw.h et xnu / bsd / kern / syscalls.master . Les numéros d'appels système de Linux varient selon l'architecture - voir linux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h et linux / arch / x86 / include / asm / unistd_64.h - mais sont tous non négatifs. Alors , évidemment , le nombre syscall, arguments syscall, et même qui syscalls existent sont différents.

Les bibliothèques d'exécution C standard sont également différentes; Darwin hérite principalement de la libc de FreeBSD, tandis que Linux utilise généralement glibc (mais il existe des alternatives, comme eglibc et dietlibc et uclibc et Bionic).

Sans oublier que toute la pile graphique est différente; En ignorant l'ensemble des bibliothèques Cocoa Objective-C, les programmes d'interface graphique sous OS X communiquent avec WindowServer via des ports Mach, tandis que sous Linux, les programmes d'interface graphique communiquent généralement avec le serveur X via des sockets de domaine UNIX utilisant le protocole X11. Bien sûr, il y a des exceptions. vous pouvez exécuter X sur Darwin et contourner X sous Linux, mais les applications OS X ne parlent certainement pas X.

Comme le vin, si quelqu'un met le travail dans

• implémentation d'un chargeur binaire pour Mach-O
• intercepter chaque appel système XNU et le convertir en appels système Linux appropriés
• écrire des remplacements pour les bibliothèques OS X telles que CoreFoundation selon les besoins
• écrire des remplacements pour des services OS X comme WindowServer selon les besoins

puis exécuter un programme OS X "nativement" sur Linux pourrait être possible. Il y a des années, Kyle Moffet avait travaillé sur le premier élément, en créant un prototype binfmt_mach-o pour Linux, mais celui-ci n'a jamais été achevé et je ne connais aucun autre projet similaire.

(En théorie, c’est tout à fait possible et des efforts similaires ont été faits à maintes reprises; outre Wine, Linux prend en charge l’exécution de binaires à partir d’UNIX tels que HP-UX et Tru64, et le projet Glendix vise à apporter la compatibilité de Plan 9 à Linux.)

Quelqu'un a déployé des efforts pour implémenter un chargeur binaire Mach-O et un traducteur d'API pour Linux!

shinh / maloader - GitHub adopte l’approche de type Wine pour charger le binaire et intercepter / traduire tous les appels de bibliothèque dans l’espace utilisateur. Il ignore complètement les appels système et toutes les bibliothèques graphiques, mais est suffisant pour faire fonctionner de nombreux programmes de console.

Darling s'appuie sur maloader, ajoute des bibliothèques et d'autres bits d'exécution compatibles.

Pourquoi les applications OSX ne s'exécutent pas nativement sur linux:

Tout d'abord, OSX utilise un format binaire différent de celui de Linux, de sorte que Linux ne peut pas exécuter les fichiers binaires compilés pour OSX (de la même manière qu'il ne peut pas exécuter les fichiers binaires compilés pour Windows ou BSD).

Deuxièmement, si vous parlez d’applications graphiques, le toolkit d’interface graphique d’Apple Cocoa a) est uniquement disponible pour OSX et b) ne s’exécute pas au-dessus de X11.

Pourquoi il n'y a pas d'équivalent vin pour les applications OSX:

Beaucoup de travail devait être fait avant que le vin soit même à moitié utilisable. Comme il n’existe pas autant de demande d’un équivalent OSX, personne n’a encore investi le même effort dans un tel projet.

La principale raison pour laquelle les applications OS X ne s'exécutent pas sous Linux est que ces systèmes d'exploitation utilisaient des appels système différents.

Certaines réponses précédentes mentionnaient des bibliothèques mais ce n’est généralement pas le cas - Core Foundation est en grande partie une source ouverte fournie par Apple sous le nom CFLite et peut facilement être transporté sur n’importe quelle plate-forme (la version Windows d’iTunes se trouve en réalité au sommet d’un port Windows de Core Foundation et compilations, vous pouvez directement créer CFLite en utilisant clang sur une distribution Linux) et il existe également des efforts en open source pour porter l’environnement Objective-C, principalement Foundation et AppKit sur Linux, notamment GNUstep, une implémentation GNU d’OpenStep, datée du plus tôt que Apple's Cocoa (a commencé lorsqu'il y avait encore la société NeXT Computer.)

Si quelqu'un est déterminé, il peut concevoir un chargeur qui capturera chaque appel système Mach-O et le traduira en appel système Linux correspondant, ainsi que lier dynamiquement ces "contreparties" de bibliothèque open source au binaire avec la traduction ABI appropriée.

Et juste pour votre information, si vous pouvez obtenir le code source de l'application Mach-O, vous pouvez envisager de le transférer et cela peut s'avérer très simple. Par exemple, l’application TextEdit fournie avec OS X 10.6 peut être directement recompilée en reliant GNUstep après avoir supprimé quelques lignes de code CF (non critique) et donc immédiatement disponible sous Linux (sans parler de TextEdit fourni avec GNUstep). recompilation directe de l'application TextEdit de NeXTSTEP, précurseur d'OS X également, en conservant même son étiquette "© 1995 NeXT"). TextEdit est sous licence BSD.

Le 8 décembre 2012, un nouveau projet a été lancé - Darling.

http://www.darlinghq.org/