Je sais qu'il existe de nombreuses différences entre OSX et Linux, mais qu'est-ce qui les rend si différents, qui les rend fondamentalement incompatibles ?
Réponse acceptée :
L'ensemble de l'ABI est différent, pas seulement le format binaire (Mach-O contre ELF) comme mentionné par sepp2k.
Par exemple, alors que Linux et Darwin/XNU (le noyau d'OS X) utilisent sc sur PowerPC et int 0x80 /sysenter /syscall sur x86 pour l'entrée syscall, il n'y a plus grand-chose en commun à partir de là.
Darwin dirige les nombres d'appels système négatifs vers le micro-noyau Mach et les nombres d'appels 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'appel 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. Donc, évidemment, les numéros d'appel système, les arguments d'appel système et même qui les appels système existants 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 la glibc (mais il existe des alternatives, comme eglibc et dietlibc et uclibc et Bionic).
Sans oublier que toute la pile graphique est différente; ignorant l'ensemble des bibliothèques Cocoa Objective-C, les programmes GUI sous OS X communiquent avec WindowServer via les ports Mach, tandis que sous Linux, les programmes GUI communiquent généralement avec le serveur X via des sockets de domaine UNIX en utilisant le protocole X11. Bien sûr, il y a des exceptions; vous pouvez exécuter X sur Darwin, et vous pouvez contourner X sur Linux, mais les applications OS X ne parlent certainement pas X.
Comme Wine, si quelqu'un met le travail dans
- implémenter un chargeur binaire pour Mach-O
- piéger chaque appel système XNU et le convertir en appels système Linux appropriés
- écriture de remplacements pour les bibliothèques OS X telles que CoreFoundation selon les besoins
- écriture de remplacements pour les services OS X comme WindowServer selon les besoins
alors exécuter un programme OS X "nativement" sur Linux pourrait être possible. Il y a des années, Kyle Moffet a travaillé sur le premier élément, créant un prototype binfmt_mach-o pour Linux, mais il 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 à plusieurs reprises; en plus de Wine, Linux lui-même prend en charge l'exécution de binaires d'autres UNIX comme HP-UX et Tru64, et le projet Glendix vise à apporter la compatibilité Plan 9 à Linux.)
Quelqu'un a faites l'effort d'implémenter un chargeur binaire Mach-O et un traducteur d'API pour Linux !
shinh/maloader - GitHub adopte l'approche de type Wine consistant à charger le binaire et à piéger/traduire tous les appels de bibliothèque dans l'espace utilisateur. Il ignore complètement les appels système et toutes les bibliothèques liées aux graphiques, mais est suffisant pour faire fonctionner de nombreux programmes de console.
Connexe :Linux – Comment afficher le message de bienvenue sous Unix ??Darling s'appuie sur maloader, en ajoutant des bibliothèques et d'autres éléments d'exécution compatibles.