Faisons tout d’abord un bref retour en arrière. Lorsque MacOS X Server a été présenté par Steve Jobs il y a un an, les développeurs ont appris qu’il leur faudrait entièrement réécrire leurs applications pour pouvoir profiter de toutes les fonctions avancées de ce nouveau système (multitâche, mémoire protégée, etc.). Une seconde solution, bien plus économique mais procurant aussi de bien moindres performances, consistait à utiliser la boîte de compatibilité MacOS. Connue successivement sous les noms BlueBox, MacOS.app et maintenant Classic, ce « système dans le système » permet aux utilisateurs du prochain MacOS X de faire fonctionner les applications prévues pour l’actuel MacOS. Histoire de ne pas être obligé de racheter toute leur logithèque. Revers de la médaille, donc, les applications sont plus lentes et elles n’utilisent pas les fonctions modernes de MacOS X.
D’où l’idée de créer une autre »boîte » dont le but est de faire tourner, en mode « natif », les applications sous MacOS X et MacOS 9. Pour ce faire, les applications doivent subir une étape de traduction, très largement automatisée. Cette »boîte » est appelée Carbon, d’où le terme d’application « carbonisée ». Cela signifie juste que l’application utilise Carbon pour fonctionner.
Mais à quoi sert exactement Carbon ? Carbon est avant toute chose une ToolBox (ensemble des routines système qu’un développeur utilise) améliorée et épurée de seize années de rajouts et de modifications successifs. Pour faire simple, Carbon est un pont permettant de faire fonctionner une même application sous MacOS 9 et MacOS X. Carbon est présent dans ces deux systèmes. Une application « carbonisée » tournant sous MacOS 9 n’offrira évidemment pas les fonctions modernes de MacOS X. Pour l’utilisateur, une application carbonisée est identique à toutes les autres applications MacOS. Pour les développeurs, l’utilisation de Carbon évite de réécrire entièrement son application pour qu’elle fonctionne sous MacOS X.
Si Carbon est une solution appréciable pour les développeurs, est-elle une solution viable à long terme ? Non. Carbon n’est qu’une transition vers le tout MacOS X. Si Carbon permet effectivement, avec un minimum d’effort, de faire fonctionner des applications sous MacOS 9 et MacOS X, rien ne vaut une application native, développée uniquement pour MacOS X sous Cocoa. Cocoa est un ensemble de librairies pour les développeurs et elles sont au coeur des applications natives MacOS X. Mais Cocoa est aussi disponible sous Windows pour développer ou déployer des projets WebObjects. Les spécifications de Cocoa, anciennement nommé OpenStep puis Yellow Box, répondent aux exigences des développeurs actuels : librairies objets, programmation en Objective C (dérivée du langage C) ou directement en Java.
Finalement, si de plus en plus d’applications seront carbonisées, les applications Cocoa les supplanteront progressivement offrant des performances bien supérieures aux applications carbonisées car totalement intégrées à MacOS X. Le seul intérêt de Carbon est de pouvoir adapter rapidement les applications à MacOS X mais aussi de continuer à les utiliser sous MacOS 9 pendant deux ou trois ans, le temps que MacOS X se généralise sur le plus grand nombre de Mac.
Pour en savoir plus : MacOS X
Microsoft lance Phi-3-mini, un petit modèle de langage (SLM) qui s'adresse aux entreprises ne disposant…
Quelle part d’incertitude faut-il accepter dans la mise en conformité des IA avec le RGPD…
Microsoft a dévoilé les prix des mises à jour de sécurité étendues pour Windows 10.…
Docaposte a sélectionné une douzaine de spécialistes français pour créer un Pack cybersécurité spécialement étudié…
La Surface Pro 10 sera disponible le 9 avril en France. Passage en revue de…
Que réserve Office 2024 ? Une première version de test officielle sera disponible en avril.…