Carbon - Cocoa : le Match !

20/07/03, par GG- Il est souvent de bon ton, en ces jours de migration vers Mac OS X, de dire d'une application qui a décidé de passer définitivement vers Mac OS X en abandonnant Mac OS 9 : "ah, ça y est, c'est enfin une application Cocoa !". Cette assertion, pourtant, est bien souvent fausse. Par ailleurs, on a souvent tendance également à penser qu'une application Cocoa est une application optimisée pour Mac OS X, alors qu'une application Carbon est là pour faire passer le temps en attendant de passer à Cocoa. Tout ceci démontre en réalité deux choses bien distinctes :

- Qu'Apple a mal communiqué sur la différence entre Cocoa et Carbon ;

- Qu'il y a beaucoup d'incompréhensions sur l'intérêt de Carbon.

Le but de ce petit dossier est donc de vous expliquer un peu plus à quoi servent Carbon et Cocoa, pourquoi ils sont là, et où ils vont. Mais avant de commencer, j'aimerais juste attirer votre attention sur le fait que mes commentaires ne sont pas ceux d'un programmeur. Par conséquent, il se peut qu'il y ait quelques points qui méritent discussion. Dans ce cas, n'hésitez pas à me contacter.

Des origines de Carbon et de Cocoa

Pour bien comprendre les origines de Cocoa et de Carbon, il faut remonter dans le temps à grands coups de Dolorean… En 1997, très exactement. A ce moment, Apple annonce le rachat de NeXT, et le grand chantier de migration des applications doit commencer rapidement, parce qu'on est quand même super à la bourre sur le marché des OS, faut pas l'oublier. Et là, douche froide pour les programmeurs : Apple leur annnonce que pour migrer vers Mac OS X, les anciennes applications applications de Mac OS vont devoir être intégralement réécrites, tout en coupant toute compatibilité avec les anciennes versions de Mac OS. En effet, les applications pour Mac OS sont écrites essentiellemen en C++, alors que Mac OS X demande aux applications d'être écrites en Objective-C, le langage de NeXTStep. A l'époque, Mac OS X aurait donc dû ressembler à ça :

En réalité, ce schéma n'est pas tout à fait exact : Quartz n'existait pas encore car il n'a été montré qu'en 2000, mais pour faciliter la compréhension, je l'ai adapté un chouïa pour qu'il ressemble à celui de l'architecture actuelle de Mac OS X, qui va bientôt suivre. Déjà que c'est bien compliqué cette histoire, si j'en rajoute dans la complexité, on a pas fini.

La réaction à cette annonce ne se fait pas attendre : la grogne se fait ressentir parmi les programmeurs, qui décident de faire comprendre à Steve et sa clique que ça va pas être gagné de faire passer tout le monde sous X si y'a pas d'applis, d'autant plus qu'ils vont devoir développer simultanément deux versions de leurs logiciels, une pour Mac OS et l'autre pour Mac OS X ! Et on le sait, un bon développeur est un développeur feignant (c'est eux même qui le disent).

Steve attrape donc les équipes de développeurs, et après leur avoir copieusement cassé la gueule (ok, j'image un peu) leur demande de revoir leur copie. La solution apparait quelques mois plus tard, en mai 1999 pour être précis, avec l'apparition officielle de Carbon. Carbon est né de l'idée suivante : pouvoir fournir aux développeurs les éléments nécessaires en C++ pour que leurs applications deviennent optimisées pour Mac OS X, c'est à dire, capables de fonctionner dans Mac OS X en bénéficiant de tous les avantages ou presque de Mac OS X. Et on obtient alors le schéma suivant :

C'est le schéma qui décrit actuellement Mac OS X. Notez que j'ai mis de la même couleur Carbon ET Cocoa, car ils partagent une caractéristique commune : ce sont, tout autant l'un que l'autre, des environnements de programmation NATIFS de Mac OS X.

Mais alors,c'est quoi une application Carbon ?

Une application Carbon est une application à la base créée sous Mac OS ante X, et dont une partie des API (Application Programming Interface, ou interfaces de programmation d'application) a été remplacée par de nouvelles API natives de Mac OS X. En clair : on remplace une partie de l'application qui n'a pas été prévue pour fonctionner sous Mac OS X de façon optimisée, par de nouvelles interfaces natives Mac OS X. Imaginez un petit peu une API comme une sorte de "tunnel" vers les fonctions de Mac OS X : quand une application veut par exemple afficher une fenêtre à l'écran, elle fait appel aux fonctions de Quartz. Et pour faire appel à Quartz, le développeur passe par Carbon, qui transmet ensuite la commande à la couche Quartz. Conclusion : les applications Carbon et Cocoa font EXACTEMENT la même chose, mais avec une langue différente. Si vous demandez à un serveur du troquet du coin "un café s'il vous plait", il vous rammènera normalement un café. Si vous lui demandez "A Coffee, please", le résultat est le même (le sourire en option, ça dépend du serveur, et le pourboire aussi d'ailleurs). Deux langues différentes, résultat identique, c'est la même chose pour Carbon et Cocoa.

Mais une application Carbon est pourtant systématiquement compatible Mac OS 9 et Mac OS X !

Et bien non, c'est faux. Et c'est là un des gros problèmes de compréhension avec les applications Carbon. On pense souvent que Carbon = compatible 9 + X. Or, les exemples d'applications Carbon non compatibles avec Mac OS 9 sont légions…

Je schématise, mais le programmeur qui compile son logiciel Carbonisé peut, lors de la compilation, demander à préparer son projet Carbon pour qu'il tourne uniquement sous Mac OS X OU dans les deux environnements. En réalité, c'est même plus compliqué que ça, puisqu'une application Carbon peut contenir deux applications *différentes*.

Un exemple ? AppleWorks 6.2.4 Lorsque l'on effectue cette mise à jour sur l'application AppleWorks 6, on se rend compte que lorsqu'on lance l'application dans Mac OS X, elle est indiquée comme étant une 6.2.4
Normal. Mais si on relance AppleWorks en version classique, on passe alors en... 6.2.3 !!! Eh oui, il y a deux applications dans AppleWorks 6.2.4 : la 6.2.4 Carbon qui fonctionne uniquement en X, et la version Classic qui fonctionne uniquement sous 8.1 à 9.x. On peut s'en assurer à l'aide d'un petit Contrôle-Clic sur l'icône d'AppleWorks, pour choisir Afficher le contenu du progiciel. Et là, on trouve deux dossiers, l'un nommé MacOS, qui contient la version Carbon, et l'autre ,MacOSClassic, qui contient… et oui, bravo Madame, c'est bien ça, la version Classic. Incroyable n'est-ce pas ?

Quelles sont les différences entre Carbon et Cocoa alors ?

En réalité, il y en a de moins en moins, et Apple travaille à atténuer toute différence entre les deux environnements. Quelques preuves :

Toutes ces fonctionnalités (palette de couleurs à la NeXT, palette de polices, Services) étaient réservées, jusqu'à Mac OS X 10.2, exclusivement aux applications Cocoa. Mais à l'arrivée de Panther… Surprise ! Les applications Carbon ont automatiquement accès aux services, et même aux fonctionnalités avancées de gestion de police et des services, comme les applications Cocoa. Cela signifie tout simplement qu'Apple a augmenté le langage de Carbon. En clair : non seulement vous pouvez demander un café au serveur, vous pouvez aussi lui demander "A cup of tea, please" ou "A bottle of Coke please", et il vous les rapportera aussi sec.

Ces ajouts sont aussi un signe fort d'Apple pour montrer que Carbon et Cocoa sont là pour cohabiter un bon bout de temps. Pas question de voir Carbon disparaitre avant quelques années, car cela signifierait tout simplement le retour vers la situation de 1997… Quasiment intolérable pour les plus gros développeurs !

A noter également : ce n'est pas parce que Safari est programmé en Cocoa qu'il est plus rapide à afficher des pages Web qu'Internet Explorer, qui est lui en Carbon. Le moteur d'affichage utilisé par l'un et par l'autre n'ont rien à voir, ce qui explique les différences de performance.

Alors, Carbon, l'arnaque du siècle ?

Pas du tout, et même au contraire. Le but de Carbon n'était pas en premier lieu de créer des applications fonctionnant parfaitement dans les deux environnements, mais surtout de fournir les éléments nécessaires pour que le développeur puisse porter la plus grande partie de son code sans trop souffrir, plutôt que de tout réécrire en Cocoa. Considérez l'éventuelle compatibilité Mac OS 9 de l'application comme un "bonus"…

Mais alors, Carbon est-il un environnement de programmation au rabais ?

Absolument pas ! Des produits comme DragThing qui sont entièrement Carbon ET compatibles 9/X sont largement à la hauteur sur bien des points d'une éventuelle version Cocoa. Son auteur dit lui-même que son produit est aussi puissant que s'il était Cocoa. Les versions récentes de DragThing savent par exemple gérer la transparence via Quartz, c'est juste du développement supplémentaire. Office v.X, par exemple, est bel et bien une application Carbon au sens propre du terme (l'application n'accède pas à toutes les fonctions de Cocoa), mais ne tourne que sous X car les programmeurs de Microsoft ont décidé d'apporter le support de certaines nouveautés de Mac OS X (comme la gestion avancée du moteur graphique Quartz ou les feuilles de dialogue attachées aux documents).

Quid de CarbonLib ?

CarbonLib est une extension système fournie par Apple en standard depuis Mac OS 9, et compatible à partir de Mac OS 8.1. Son but est de permettre aux applications Carbon encore compatibles avec Mac OS 9 de quoi causer correctement avec ce dernier. Une sorte de traducteur Carbon pour Mac OS 9. Un peu comme si cette fois-ci, on demande un café à un serveur Allemand qui comprend pas une once de français : il va pas comprendre, alors on lui donne un dico, et on lui explique ce qu'on veut, ça prend plus de temps et c'est pas forcément aussi efficace mais ça marche. Dans le cas de CarbonLib, les applications ne bénéficient pas des avantages de Mac OS X comme la mémoire protégée, la gestion dynamique de la RAM, etc. Mais elles fonctionnent comme des applications Mac OS tout ce qu'il y a de plus normal…

Alors, que choisir si on est développeur ?

En fait, si l'application part de zéro, mieux vaut faire une appli Cocoa. C'est le cas de la plupart des utilitaires système, comme le fabuleux SnapZ Pro X. Pour les extensions et tableaux de bord de Mac OS 9, même pas la peine de penser à Carbon, c'est pas fait pour ça. En revanche, s'il s'agit d'une application de productivité et non pas un utilitaire, Carbon sera probablement la meilleure solution. En fait, ça dépend surtout de la gueule du code à l'origine et de son envie d'apprendre ou non l'Objective-C. N'espérez vraiment pas voir un Photoshop Cocoa avant plusieurs années, et de toute façon, dites-vous bien que passer à Cocoa n'apporterait pas des avantages grandioses. Carbon est un environnement de migration vers Mac OS X, PAS un environnement de migration vers Cocoa. Cocoa ne doit pas être une finalité en soi, mais un ensemble à utiliser dans les cas les plus adaptés. La compatibilié avec Mac OS 9 dépend avant tout de l'utilisateur, mais de nos jours, elle ne fait plus tellement sens, car la migration vers Mac OS X est enclenchée à fond, sans aucun espoir de marcher arrière (et tant mieux, aurais-je tendance à dire).

Quelle influence de Carbon pour l'utilisateur ?

En réalité, très peu d'influence. Ce qui compte, c'est que l'application tourne de façon native sous X. Si c'est le cas, soyez joyeux. Si ce n'est pas le cas, il ne vous reste plus qu'à passer par Classic (ou redémmarer sous 9, si votre Mac le permet encore…). Les avantages notables des applications Cocoa pour l'utilisateur ont quasiment tous disparus.

Conclusion Carbonienne

Comme vous l'aurez constaté, le monde des applications Carbon/Cocoa n'est pas si évident à comprendre ! En réalité, une règle simple reste à respecter : si le logiciel est déclaré "compatible Mac OS X", c'est la seule chose qui compte. Le reste regarde surtout le programmeur. Mais il est bon de constater qu'Apple travaille dur non seulement sur Cocoa, mais peut-être encore plus dur sur Carbon, car c'est un élément indispensable à une migration fructueuse des applications vers Mac OS X. En revanche, pensez à retirer désormais de votre langage les phrases suivantes :"Cette application ne tourne que sous Mac OS X, donc elle est Cocoa", et "C'est une application Carbon, donc c'est moins bien qu'une version Cocoa" ou encore "Attendons la version Cocoa pour migrer vers cette application"…