Vous oubliez une chose cruciale, à savoir que votre programme devra interagir avec le système d'exploitation pour faire quelque chose d'intéressant.
Les conventions sont différentes entre Linux et OS X, de sorte que le même binaire ne peut pas fonctionner tel quel sans avoir essentiellement un morceau de code dépendant du système d'exploitation pour pouvoir interagir avec lui. Beaucoup de ces éléments sont fournis par le biais de bibliothèques, que vous devez ensuite lier, ce qui signifie que votre programme doit pouvoir être lié, et la liaison est également différente entre les deux systèmes.
Et ainsi de suite. Ce qui, à première vue, ressemble à faire la même chose est très différent dans les détails réels.
C'est faisable si quelqu'un veut passer suffisamment de temps pour y arriver. Le projet Darling tente cela, bien qu'au moment d'écrire ces lignes, il soit dans un état assez primitif.
Cela a déjà été fait avec succès sur d'autres plates-formes :
-
Solaris et UnixWare incluent un programme d'assistance appelé
lxrunqui fonctionne quelque chose commesudo:vous transmettez votre nom d'exécutable et vos paramètres à l'assistant et il corrige les choses dynamiquement afin que l'exécutable puisse parler au système d'exploitation. Le site officiel (en bas, lien d'archive) indique qu'il est bitrotté. -
Le noyau de Linux avait autrefois une fonctionnalité appelée iBCS qui faisait l'inverse, sauf qu'il n'avait pas besoin d'aide car le noyau reconnaissait directement les binaires "étrangers". Il est tombé en ruine pendant la série de développement du noyau 2.3, probablement parce que la petite bataille des serveurs Unix était essentiellement terminée une fois que le 2.4 est sorti.
-
Le noyau de FreeBSD peut être configuré pour reconnaître les binaires Linux et les exécuter comme s'ils étaient natifs. Cette fonctionnalité semble être en meilleure forme que les deux précédentes.
OpenBSD et NetBSD ont des fonctionnalités similaires.
OS X contient beaucoup de FreeBSD, donc le portage de son support Linux peut être simple.
Je suis à peu près d'accord avec tout le monde, mais je tiens à ajouter que, même si cela prendrait beaucoup de temps et d'efforts, ce ne serait pas autant qu'il en a fallu pour développer Wine.
Une grande partie de la difficulté du développement de Wine réside dans le fait qu'ils portent un format binaire à partir d'un système d'exploitation à source fermée et que BEAUCOUP d'appels système ne sont pas documentés. Ils ont dû essentiellement désosser le système d'exploitation.
Si quelqu'un devait le faire d'un système d'exploitation ouvert à un autre système d'exploitation ouvert, il pourrait probablement le faire en 1/10 du temps, car la couche de compatibilité pourrait très bien être copiée/collée depuis l'autre système d'exploitation si un appel système natif équivalent n'existe pas. Bien sûr, dans la plupart des cas dans le monde POSIX, un appel natif sera disponible.
Un autre projet à noter est ReactOS, où ils créent essentiellement une version entièrement compatible binaire de Windows... pas besoin de Wine.