Étant donné que le système d'exploitation Apple OS-X est un dérivé UNIX (BSD) et que l'architecture Mac sous-jacente (Intel) est la même, pourquoi n'est-il pas très simple de faire fonctionner des applications spécifiques à Apple sous Linux?
Étant donné que le système d'exploitation Apple OS-X est un dérivé UNIX (BSD) et que l'architecture Mac sous-jacente (Intel) est la même, pourquoi n'est-il pas très simple de faire fonctionner des applications spécifiques à Apple sous Linux?
Réponses:
OS X est en fait (principalement) le shell graphique propriétaire au-dessus de BSD. Pour créer une application graphique OS X, il faut suivre l'api qu'Apple a exposé, et donc ce n'est pas multiplateforme et pas facilement portable.
C'est pourquoi la plupart des bibliothèques sont facilement portées (en fait, la plupart sont développées sous Linux) vers Linux mais pas leurs shells graphiques.
Sur une note latérale: Il existe des cadres avec lesquels vous pouvez créer des applications GUI multiplateformes. Qt me vient à l'esprit. Mais le fait que ces cadres soient multiplates-formes rend également les applications créées avec eux moins conviviales sur une plate-forme spécifique qu'une application GUI "native". Ces cadres ont tendance à donner à tout un aspect générique sur toutes les plates-formes, ce qui dans le cas d'Apple est mauvais, car Apple a créé une expérience utilisateur très spécifique qui ne s'intègre pas facilement dans d'autres plates-formes.
Modifier (pour incorporer les commentaires dans la réponse - merci @Nick, @kbisset et @John):
Une solution serait de porter l'intégralité du shell graphique OS X (les bibliothèques Cocoa / Core à source fermée - ce qui rend OS X vraiment unique ) à Linux. Et techniquement, Apple pourrait le faire assez facilement, mais ils n'ont aucune raison de le faire, car tout leur modèle commercial est l'unicité de l'ensemble de leur plate-forme - matériel et logiciel.
Il est CONCEVABLE que quelqu'un puisse tenter de cloner les bibliothèques, mais cela prendrait des décennies à faire, et ne serait probablement jamais correct à cause de tous les appels non documentés qui devraient être répliqués.
Par applications spécifiques à Apple, entendez-vous des applications GUI? Une fois que vous vous déplacez au-dessus de la ligne de commande, il existe des API spécifiques à Apple pour tout (graphiques, sons, etc.) qui ne sont pas prises en charge sous Linux, vous ne pouvez donc pas facilement porter des applications.
La couche graphique n'est pas du tout la même. OS X utilise un cadre graphique propriétaire, linux utilise X (X11 / X.org)
Presque toutes les applications natives OS X utilisent des cadres tels que Cocoa, CoreAnimation et ainsi de suite, qui ne sont disponibles que sur OS X.
Par exemple, supposons que vous ayez une application qui stocke un mot de passe pour l'utilisateur - sur OS X, cela utiliserait son système de trousseau et les API pertinentes. Si vous deviez porter cela sur Linux, il n'y a pas d'équivalent direct, vous devrez donc réimplémenter toute cette fonctionnalité. C'est une toute petite fonctionnalité qui nécessiterait une réécriture importante.
Si vous écrivez votre application à l'aide d'une bibliothèque d'interfaces graphiques comme GTK, Qt ou wxWidgets, le portage sera beaucoup plus facile (ou «possible») - mais les systèmes d'exploitation sont toujours très différents en termes d'interface utilisateur (par exemple, OS X utilise une barre de menus séparée, alors que Linux a tendance à avoir sa barre de menus pour chaque fenêtre)
L'un des meilleurs ports multiplateformes que j'ai vus est Transmission , qui implémente ses principales fonctionnalités en tant que bibliothèque (qui contient le moins de code spécifique à la plate-forme possible), puis crée des interfaces graphiques natives pour chaque plate-forme, séparément. Cela signifie que chaque port partage beaucoup de code, mais tous ont de bonnes interfaces natives (plutôt qu'une interface unique qui s'intègre bien sous Linux, mais qui n'est pas à sa place sous OS X, ou vice versa)
Il existe un projet appelé Cocotron qui "vise à implémenter une API Objective-C multiplateforme similaire à celle décrite par la documentation Cocoa d'Apple Inc." qui pourrait potentiellement faciliter le portage, mais il semble y avoir très peu d'activité ces derniers temps (le dernier article de blog date de décembre 2008)
Parce que la plupart des applications dépendent de bien plus que du processeur et de l'architecture sous-jacente de la machine sur laquelle ils s'exécutent. Ils dépendent également des boîtes à outils de l'interface utilisateur et d'autres bibliothèques spécifiques à la plate-forme.