Carbone (API)

Carbon était l'une des deux principales interfaces de programmation d'applications (API) basées sur C développées par Apple pour le système d'exploitation macOS (anciennement Mac OS X et OS X) . Carbon offrait un bon degré de rétrocompatibilité pour les programmes exécutés sur Mac OS 8 et 9. Les développeurs pouvaient utiliser les API Carbon pour porter (« carboniser ») leurs applications et logiciels Mac « classiques » sur la plateforme Mac OS X avec peu d'efforts, par rapport au portage de l'application sur le système Cocoa entièrement différent , qui est né dans OPENSTEP . Avec la sortie de macOS 10.15 Catalina , l'API Carbon a été officiellement abandonnée et supprimée, laissant Cocoa comme seule API principale pour le développement d'applications macOS.

Carbon a joué un rôle important dans la stratégie d'Apple pour commercialiser Mac OS X, offrant un moyen de portage rapide des applications logicielles existantes, ainsi qu'un moyen de livrer des applications qui fonctionneraient soit sur Mac OS X, soit sur le Mac OS classique. Comme le marché s'est de plus en plus tourné vers les frameworks basés sur Cocoa, en particulier après la sortie d' iOS , le besoin d'une bibliothèque de portage a été réduit. Apple n'a pas créé de version 64 bits de Carbon lors de la mise à jour de ses autres frameworks au cours de la période 2007, et a finalement abandonné l'intégralité de l'API dans OS X 10.8 Mountain Lion , qui a été publié le 24 juillet 2012.

Le système d'exploitation Mac OS d'origine utilisait Pascal comme plate-forme de développement principale et les API étaient largement basées sur la sémantique d'appel de Pascal . Une grande partie de la boîte à outils Macintosh était constituée d' appels de procédures , transmettant des informations dans les deux sens entre l'API et le programme à l'aide de diverses structures de données basées sur le concept d'enregistrement de variantes de Pascal .

Au fil du temps, un certain nombre de bibliothèques d'objets ont évolué sur Mac, notamment la bibliothèque Object Pascal MacApp et la bibliothèque THINK C Think Class, ainsi que les versions ultérieures de MacApp et PowerPlant de CodeWarrior en C++ .

Avec l'achat de NeXT fin 1996, Apple a développé une nouvelle stratégie de système d'exploitation basée en grande partie sur la plate-forme OPENSTEP for Mach existante . La nouvelle stratégie Rhapsody OS était relativement simple ; elle conservait la plupart des bibliothèques d'objets existantes d'OpenStep sous le nom de « Yellow Box », transposait l' interface graphique existante dans OPENSTEP for Mach et la rendait plus proche de celle de Mac, transposait plusieurs API majeures de Mac OS vers le système sous-jacent de type Unix de Rhapsody (notamment QuickTime et AppleSearch ), et ajoutait un émulateur connu sous le nom de « Blue Box » qui exécutait les logiciels Mac OS existants.

Lorsque ce plan fut dévoilé à la Worldwide Developers Conference (WWDC) en 1997, il y eut une certaine opposition de la part des développeurs Mac OS existants, mécontents de voir leurs bases de code effectivement enfermées dans un émulateur qui ne serait probablement jamais mis à jour. Ils ont pris l'habitude d'appeler la Blue Box la « boîte de pénalité ». Les développeurs plus importants comme Microsoft et Adobe ont carrément hésité et ont refusé d'envisager le portage vers OpenStep, qui était si différent du système d'exploitation Mac OS existant qu'il n'y avait que peu ou pas de compatibilité.

Apple a pris ces préoccupations à cœur. Lorsque Steve Jobs a annoncé le changement de direction d'Apple lors de la WWDC suivante en 1998, il a déclaré que « ce que les développeurs voulaient vraiment, c'était une version moderne de Mac OS, et Apple allait la leur fournir ».

Le concept original de Rhapsody, avec uniquement la Blue Box pour exécuter les logiciels Mac OS existants, a finalement été publié en 1999 sous le nom de Mac OS X Server 1.0 . Il s'agissait de la seule version basée sur le concept original de Rhapsody.

Afin d'offrir un chemin de mise à niveau réel et bien pris en charge pour les bases de code Mac OS existantes, Apple a introduit le système Carbon. Carbon se compose de nombreuses bibliothèques et fonctions qui offrent une API de type Mac, mais fonctionnant sur le système d'exploitation sous-jacent de type Unix, plutôt qu'une copie du système d'exploitation Mac fonctionnant en émulation. Les bibliothèques Carbon ont été largement nettoyées, modernisées et mieux « protégées ». Alors que le système d'exploitation Mac OS était rempli d'API qui partageaient la mémoire pour transmettre des données, sous Carbon, tous ces accès ont été réimplémentés à l'aide de sous-routines d'accès sur des types de données opaques . Cela a permis à Carbon de prendre en charge le véritable multitâche et la protection de la mémoire , des fonctionnalités que les développeurs Mac demandaient depuis une décennie. D'autres modifications de l'API préexistante ont supprimé des fonctionnalités qui étaient conceptuellement incompatibles avec Mac OS X, ou simplement obsolètes. Par exemple, les applications ne pouvaient plus installer de gestionnaires d'interruptions ou de pilotes de périphériques .

Afin de prendre en charge Carbon, l'ensemble du modèle Rhapsody a changé. Alors que Rhapsody serait en fait OpenStep avec un émulateur, dans le cadre du nouveau système, les API OpenStep et Carbon partageraient, dans la mesure du possible, un code commun. Pour ce faire, de nombreux morceaux de code utiles des niveaux inférieurs du système OpenStep, écrits en Objective-C et connus sous le nom de Foundation, ont été réimplémentés en C pur. Ce code est devenu connu sous le nom de Core Foundation , ou CF en abrégé. Une version de Yellow Box portée pour appeler CF est devenue la nouvelle API Cocoa , et les appels de Carbon de type Mac appelaient également les mêmes fonctions. Dans le nouveau système, Carbon et Cocoa étaient homologues. Cette conversion aurait normalement ralenti les performances de Cocoa car les méthodes d'objet appelaient les bibliothèques C sous-jacentes, mais Apple a utilisé une technique appelée pontage sans frais pour réduire cet impact.

Dans le cadre de cette conversion, Apple a également porté le moteur graphique du Display PostScript sous licence vers le Quartz sans licence (qui a été appelé « Display PDF »). Quartz fournissait des appels natifs qui pouvaient être utilisés à partir de Carbon ou de Cocoa, ainsi que des interfaces de type Java 2D . Le système d'exploitation sous-jacent lui-même a été isolé davantage et publié sous le nom de Darwin .

Carbon a été introduit sous une forme incomplète en 2000, en tant que bibliothèque partagée rétrocompatible avec Mac OS 8.1 de 1997. Cette version permettait aux développeurs de porter leur code vers Carbon sans perdre la capacité de ces programmes à s'exécuter sur des machines Mac OS existantes. Le portage vers Carbon est devenu connu sous le nom de « carbonisation ». Le support officiel de Mac OS X est arrivé en 2001 avec la sortie de Mac OS X v10.0 , la première version publique du nouveau système d'exploitation. Carbon a été très largement utilisé dans les premières versions de Mac OS X par presque tous les principaux éditeurs de logiciels, même par Apple. Le Finder , par exemple, est resté une application Carbon pendant de nombreuses années, n'étant porté sur Cocoa qu'avec la sortie de Mac OS X 10.6 en 2009.

La transition vers les applications Macintosh 64 bits à partir de Mac OS X v10.5 , sorti le 26 octobre 2007, a apporté les premières limitations majeures à Carbon. Apple n'offre pas de compatibilité entre l' interface utilisateur graphique Macintosh et le langage de programmation C dans l'environnement 64 bits, exigeant à la place l'utilisation du dialecte Objective-C avec l'API Cocoa. De nombreux commentaires ont pris cela comme le premier signe de la disparition éventuelle de Carbon, une position qui a été renforcée lorsque Apple a déclaré qu'aucun nouvel ajout majeur ne serait ajouté au système Carbon, et encore renforcée avec son abandon en 2012.

Malgré les avantages supposés de Cocoa, la nécessité de réécrire de grandes quantités de code hérité a ralenti la transition des applications basées sur Carbon, notamment avec Adobe Photoshop qui a finalement été mis à jour vers Cocoa en avril 2010. Cela s'est également étendu aux logiciels phares d'Apple, comme iTunes et Final Cut Pro (ainsi que les fonctionnalités du moteur QuickTime qui le fait fonctionner ) qui sont restés écrits en Carbon pendant de nombreuses années. iTunes et Final Cut Pro X ont depuis été publiés dans des versions Cocoa.

En 2012, avec la sortie d'OS X 10.8 Mountain Lion, la plupart des API Carbon ont été considérées comme obsolètes. Les API étaient toujours accessibles aux développeurs et toutes les applications Carbon fonctionnaient toujours, mais les API ne seraient plus mises à jour. Le 28 juin 2017, Apple a annoncé que les logiciels 32 bits pour macOS, tels que toutes les applications Carbon, ne seraient plus pris en charge « sans compromis » sur les versions de macOS après macOS 10.13 High Sierra . macOS 10.15 Catalina a officiellement supprimé la prise en charge des applications 32 bits, y compris toutes les applications Carbon.

Carbon est issu de la Toolbox , et en tant que tel, est composé de « gestionnaires ». Chaque gestionnaire est une API fonctionnellement liée, définissant des ensembles de structures de données et des fonctions pour les manipuler. Les gestionnaires sont souvent interdépendants ou superposés. Carbon se compose d'un large ensemble de fonctions pour gérer les fichiers, la mémoire, les données, l'interface utilisateur et d'autres services système. Il est implémenté comme n'importe quelle autre API : dans macOS, il est réparti sur plusieurs frameworks (chacun étant une structure construite autour d'une bibliothèque partagée ), principalement Carbon.framework, ApplicationServices.framework, et CoreServices.framework, et dans Mac OS classique, il réside dans une seule bibliothèque partagée nommée CarbonLib.

En tant que terme générique englobant toutes les procédures API en langage C accédant aux fonctionnalités spécifiques à Mac, Carbon n'est pas conçu comme un système discret. Au contraire, il ouvre presque toutes les fonctionnalités de macOS aux développeurs qui ne connaissent pas le langage Objective-C requis pour l' API Cocoa largement équivalente .

Carbon est compatible avec tous les formats exécutables disponibles pour PowerPC Mac OS. La compatibilité binaire entre Mac OS X et les versions précédentes nécessite l'utilisation d'un fichier de format exécutable préféré , qu'Apple n'a jamais pris en charge dans son IDE Xcode .

Les parties les plus récentes de Carbon ont tendance à être beaucoup plus orientées objet dans leur conception, la plupart d'entre elles étant basées sur Core Foundation . Certains gestionnaires, tels que HIView Manager (un sur-ensemble de Control Manager), sont implémentés en C++ , mais Carbon reste une API C.

Quelques exemples de Carbon Managers :

• Gestionnaire de fichiers — gère l'accès au système de fichiers, l'ouverture, la fermeture, la lecture et l'écriture des fichiers.
• Gestionnaire de ressources : gère l'accès aux ressources, qui sont des blocs de données prédéfinis dont un programme peut avoir besoin. Appelle le Gestionnaire de fichiers pour lire et écrire des ressources à partir de fichiers sur disque. Les exemples de ressources incluent les icônes, les sons, les images, les modèles pour les widgets, etc.
• Gestionnaire de polices : gère les polices . Obsolète (en tant qu'élément de QuickDraw ) depuis Mac OS X v10.4 , au profit d' Apple Type Services (ATS).
• QuickDraw — Primitives graphiques 2D. Obsolète depuis Mac OS X v10.4 , au profit de Quartz 2D.
• Carbon Event Manager — convertit l'activité des utilisateurs et du système en événements que le code peut reconnaître et auxquels il peut répondre.
• HIObject — une API orientée objet complètement nouvelle qui apporte à Carbon un modèle OO pour la création d'interfaces graphiques. HIToolbox dans Mac OS Classic et Copland s'appuyait sur le modèle d'objet système IBM abandonné , donc Carbon a dû fournir un remplacement rapide et sale pour permettre le portage du code existant. Ceci est disponible dans Mac OS X v10.2 ou version ultérieure, et donne aux programmeurs Carbon certains des outils que les développeurs Cocoa connaissent depuis longtemps. À partir de Mac OS X v10.2 , HIObject est la classe de base pour tous les éléments d'interface graphique dans Carbon. HIView est pris en charge par Interface Builder , qui fait partie des outils de développement d'Apple. Traditionnellement, les architectures d'interface graphique de ce type ont été laissées à des frameworks d'application tiers. À partir de Mac OS X v10.4, les HIObjects sont des NSObjects et héritent de la capacité d'être sérialisés dans des flux de données pour le transport ou l'enregistrement sur disque.
• HITheme — utilise QuickDraw et Quartz pour afficher les éléments de l'interface utilisateur graphique (GUI) à l'écran. HITheme a été introduit dans Mac OS X v10.3 et Appearance Manager est une couche de compatibilité au-dessus de HITheme depuis cette version.
• HIView Manager — gère la création, le dessin, les tests de frappe et la manipulation des contrôles. Depuis Mac OS X v10.2, tous les contrôles sont des HIViews. Dans Mac OS X v10.4, le gestionnaire de contrôles a été renommé HIView Manager.
• Gestionnaire de fenêtres : gère la création, le positionnement, la mise à jour et la manipulation des fenêtres. Depuis Mac OS X v10.2, les fenêtres ont une racine HIView.
• Gestionnaire de menus — gère la création, la sélection et la manipulation des menus. Depuis Mac OS X v10.2, les menus sont des HIObjects. Depuis Mac OS X v10.3, le contenu des menus peut être dessiné à l'aide de HIViews, et tous les menus standard utilisent HIViews pour dessiner.

Le gestionnaire d'événements de la boîte à outils Mac utilisait à l'origine un modèle d'interrogation pour la conception d'applications. La boucle d'événements principale de l'application demande au gestionnaire d'événements un événement à l'aide de GetNextEvent. S'il y a un événement dans la file d'attente, le gestionnaire d'événements le renvoie à l'application, où il est traité, sinon il revient immédiatement. Ce comportement est appelé « attente occupée », exécutant la boucle d'événements inutilement. L'attente occupée réduit la quantité de temps CPU disponible pour d'autres applications et diminue la puissance de la batterie sur les ordinateurs portables. Le gestionnaire d'événements classique date du système d'exploitation Mac d'origine en 1984, lorsque toute application en cours d'exécution était garantie d'être la seule application en cours d'exécution et où la gestion de l'alimentation n'était pas un problème.

Avec l’avènement de MultiFinder et la possibilité d’exécuter plusieurs applications simultanément, un nouvel appel de gestionnaire d’événements, WaitNextEvent , est apparu , qui permet à une application de spécifier un intervalle de veille. Une astuce simple pour que le code hérité adopte un modèle plus efficace sans modifier considérablement son code source consiste simplement à définir le paramètre sleep passé à WaitNextEvent sur une valeur très élevée. Sous macOS, cela met le thread en veille lorsqu’il n’y a rien à faire et ne renvoie un événement que lorsqu’il y en a un à traiter. De cette façon, le modèle d’interrogation est rapidement inversé pour devenir équivalent au modèle de rappel, l’application effectuant sa propre répartition d’événements de la manière d’origine. Il existe cependant des failles. Par exemple, l’appel de boîte à outils hérité ModalDialog , par exemple, appelle l’ancienne fonction GetNextEvent en interne, ce qui entraîne une interrogation dans une boucle serrée sans blocage.

Carbon introduit un système de remplacement, appelé Carbon Event Manager. (Le gestionnaire d'événements d'origine existe toujours pour assurer la compatibilité avec les applications existantes). Carbon Event Manager fournit la boucle d'événements pour le développeur (basée sur celle de Core Foundation CFRunLoopdans l'implémentation actuelle) ; le développeur configure les gestionnaires d'événements et entre dans la boucle d'événements dans la fonction principale, et attend que Carbon Event Manager envoie les événements à l'application.

Dans le système d'exploitation Mac OS classique, le système d'exploitation ne prenait pas en charge les temporisateurs au niveau des applications (le gestionnaire de temps de niveau inférieur était disponible, mais il exécutait les rappels de temporisateur au moment de l'interruption, pendant lequel les appels à la plupart des routines de la boîte à outils ne pouvaient pas être effectués en toute sécurité). Les temporisateurs étaient généralement laissés aux développeurs d'applications pour être mis en œuvre, et cela se faisait généralement en comptant le temps écoulé pendant l' événement d'inactivité , c'est-à-dire un événement renvoyé par WaitNextEvent lorsqu'aucun autre événement n'était disponible. Pour que ces temporisateurs aient une résolution raisonnable, les développeurs ne pouvaient pas se permettre de trop retarder WaitNextEvent , et donc des paramètres de « veille » bas étaient généralement définis. Cela se traduit par un comportement de planification très inefficace, car le thread ne se met pas en veille très longtemps, mais se réveille à plusieurs reprises pour renvoyer ces événements d'inactivité. Apple a ajouté la prise en charge des temporisateurs à Carbon pour résoudre ce problème : le système peut planifier les temporisateurs avec une grande efficacité.

GNUstep contient une implémentation de l'API Carbon appelée Boron. Elle vise à être compatible avec les parties non obsolètes d'ApplicationServices et CoreServices. Le nom dérive du fait que Boron vient avant Carbon dans le tableau périodique des éléments . Darling contient également une implémentation Carbon. Les deux implémentations sont très incomplètes et se composent principalement de fonctions stub.