Carbon ou Cocoa, la double casquette de MacOS X

Pour classifier très vite Carbon par rapport à Cocoa, il suffit de savoir que le premier est un ensemble de bibliothèques de programmation qui permet aux développeurs de transposer rapidement un logiciel normalement destiné à MacOS 8 ou 9 vers MacOS X (voir édition du 26 janvier 2000). Mais pour profiter de toutes les subtilités du nouveau système de la Pomme, il faut retrousser ses manches et repartir du début en utilisant les bibliothèques Cocoa. Pour mieux comprendre la genèse de cette scission, un petit historique s’impose…

MacOS 8 devait marquer la révolution du système d’exploitation d’Apple. C’était le projet Copland, qui devait être suivi de MacOS 9, nom de code Gershwin. Après l’arrêt du projet Copland, et une fois Next racheté, encore fallait-il établir une nouvelle stratégie système. Après quelques semaines de réflexion, Apple dévoila un plan ambitieux : le projet Rhapsody. Pour pouvoir établir une migration en douceur, la Pomme avait établi un plan en trois étapes : Rhapsody DR (pour les développeurs), Rhapsody Premier et Rhapsody Unifié (une sorte de version finale). Ces trois étapes amenant à une version de Rhapsody avec une évolution de l’interface Platinium et de toute une panoplie de nouvelles fonctions, bref, tout ce que nous promettait Copland, mais en mieux évidemment…

Les deux arguments majeurs de Rhapsody étaient la version PC et la Yellow Box, nom de code du tout nouvel environnement système (mémoire protégée, multi-threading, multi-tâche préemptif et non plus coopératif). La Yellow Box était indifféremment développée pour processeurs Power PC et Intel. Jusqu’à la dernière évolution de Rhapsody DR (la DR2), la version Intel était développée en parallèle et fonctionnait parfaitement. Puis, Apple a décidé une fois de plus de bouleverser sa stratégie. Rhapsody est renommé MacOS X Server 1.0 et la version PC est abandonnée. Cet OS serveur marque la rupture en introduisant des concepts inconnus sous MacOS. Si pendant de longs mois Apple misait sur le nouveau modèle de développement objet de la Yellow Box, les développeurs, tout comme les grands éditeurs, étaient plutôt réticents face à l’idée de devoir tout redévelopper. La rupture technologique était sans aucun doute intéressante, mais trop rapide.

Une boîte à outils dépoussiérée

Ni 8, ni 9, ce sera finalement MacOS X (voir notre dossier « A la découverte de MacOS X ») qui fera l’événement. Pour offrir une transition en douceur, Apple propose donc Carbon qui est donc une passerelle entre les deux mondes très différents que sont MacOS 9 et MacOS X. L’idée de Carbon est de proposer aux développeurs les fonctions modernes de MacOS X en ne modifiant qu’un minimum de code. Pour cela, les ingénieurs Apple ont repris la bonne vieille ToolBox (boîte à outils pour les développeurs) du MacOS mais en la nettoyant des éléments les plus obsolètes et les moins utilisés. Carbon n’est, au bout du compte, qu’une super ToolBox MacOS revue et corrigée pour pouvoir tirer profit des bases systèmes de MacOS X. Il ne faut pas s’y tromper, Carbon constitue une rupture avec la ToolBox actuelle. Adaptée à MacOS X, cela implique que l’on pourra profiter d’un multitâche préemptif, d’une mémoire protégée. Ces fonctions modernes obligent à posséder une ToolBox dite « réentrante ». C’est-à-dire, que l’on peut appeler en même temps la même fonction dans plusieurs applications, sans attendre la libération de ladite fonction. Bien entendu, le passage d’un système monolithique à un système moderne avec un micro-noyau implique une révision très large de la ToolBox. Les développeurs MacOS 8/9 pouvaient déjà utiliser une Toolbox toilettée, par l’intermédiaire de MacOS Universal Interfaces 3.x.

Carbon représente le modèle applicatif le plus basique et le plus simple sous MacOS X. Si effectivement une application carbonisée utilise les fonctions modernes de MacOS X, hors de question de les exploiter d’une manière optimale. Et c’est bien là le défaut de Carbon : compatibilité X oui, mais pas du tout adapté à l’architecture de MacOS X. Une application carbonisée ne sera jamais plus rapide, plus stable et plus performante qu’une véritable application MacOS X. Comment développer des applications natives pour MacOS X ? La réponse tient en un seul mot : Cocoa, un ensemble de bibliothèques de programmation qui n’est autre que la fameuse Yellow Box qui revient sous un autre nom.

Un virage délibéré vers les technologies « modernes »

Outre l’aspect purement objet, pourquoi Cocoa rend-il Carbon dépassé ? Cocoa est le véritable modèle de développement de MacOS X, il communique directement avec l’ensemble des couches basses du système (BSD pour les réseaux, Posix pour les threads, le noyau Mach 3.0, etc.), et surtout, il s’utilise avec de l’Objective C (langage historique de NextStep) ou en Java 2 (indisponible sous MacOS 9). D’autre part, l’approche objet et totalement modulaire de Cocoa permet un développement très rapide d’une application. Comme Carbon, Cocoa se compose de plusieurs éléments : EOF (Entreprise Object Frameworks) utilisé par WebObjects, Application Kit (ou AppKit) contenant tous les éléments de base pour construire une application (interface, menus, interaction, scripting, etc.) et enfin Foundation regroupant toutes les autres fonctions non liées à l’interface (gestion der la mémoire et des threads, multitâche, communication avec le réseau et le micro-noyau, etc.). Pour développer une application Cocoa, une seule et unique solution, utiliser les outils Apple (en fait, ceux créés à l’origine pour NextStep), notamment Interface et Project Builder.

Une transition qui rappelle le passage vers le PowerPC

Reste à savoir comment va se dérouler la cohabition Carbon / Cocoa. Pour Apple et les développeurs, Carbon n’a jamais été plus qu’une étape de transition entre les anciennes applications MacOS 9 et les nouvelles applications MacOS X. Le but est de rendre disponibles très rapidement le plus grand nombre d’applications dès la sortie du nouveau système d’Apple. On retrouve un peu la situation de 1994 quand la Pomme avait introduit les premières machines PowerPC. Il n’existait alors aucune application tirant réellement partie de la puissance apportée par le PowerPC par rapport aux 68 K de l’époque. Le constructeur avait donc créé un émulateur de code 68 K pour pouvoir utiliser les applications non adaptées aux PowerMac. Finalement, même si la transition dura plus de deux années, elle s’est bien passée. Et il devrait se passer la même chose entre Carbon et Cocoa. Il faudra quelque temps avant de voir apparaître des applications phares, comme Photoshop, MS Office ou Xpress, entièrement optimisées pour Cocoa. La plupart des éditeurs attendant de toute façon la version définitive de MacOS X. Ainsi, la toute dernière version d’Office, numérotée 2001, n’est pour l’instant disponible que pour MacOS 9. Normal, changer de modèle de développement nécessite du temps et de l’argent. Il n’empêche, Carbon se condamne lui-même. Même si Apple l’a toiletté, il garde la vieille structure de programmation héritée des premières versions de MacOS. Il est clair qu’Apple encourage l’utilisation de Cocoa pour toutes les applications nouvelles uniquement destinées à MacOS X.

En réalité, Apple tire les leçons de son expérience. Pour que MacOS X « fasse un carton », il lui faut des applications. Carbon est une réponse opportuniste, même si cela doit grever les performances et le support des fonctions avancées de MacOS X.