Project:Omega.org » Guide de portage UNIX

Accueil > Portage d'applications vers Mac OS X > Guide de portage UNIX

Guide de portage UNIX

02/01/2003

Traduit par Thierry, 20/11/2002.

Introduction

Mac OS X est un système d’exploitation moderne qui combine la puissance et la stabilité des systèmes d’exploitation UNIX avec la simplicité et l’élégance du Macintosh. Depuis de nombreuses années, les utilisateurs et développeurs chevronnés ont reconnu la force d’UNIX et de ses ramifications. Bien que les systèmes d’exploitation UNIX soient indispensables aux développeurs et utilisateurs expérimentés, les consommateurs ont rarement pu profiter des avantages qu’ils offrent à cause de l’image de complexité qui les caractérisent. Par contre, les consommateurs ont vécu avec une génération d’ordinateurs de bureau dont le seul espoir était d’atteindre la puissance dont les systèmes UNIX étaient dotés depuis leur début.

L’introduction de systèmes UNIX tels que FreeBSD et GNU/Linux dans les ordinateurs personnels fut une grande étape dans la démocratisation de la puissance et de la stabilitié d’UNIX. Quoiqu’en général, ces projets furent conduits par des utilisateurs et développeurs expérimentés pour leurs propres besoins, sans prendre de décisions relatives à une enveloppe esthétique séduisante pour les consommateurs. D’un autre côté, Mac OS X fut conçu en gardant la notion d’utilisateur final à l’esprit dès le début. Avec ce système d’exploitation, Apple a assis sa capacité reconnue en matière de simplicité et d’élégance sur des fondations UNIX. Au lieu de réinventer ce qui avait déjà été bien fait, Apple a réconcilié sa force avec celle fournie par des années d’évolution par la communauté UNIX. Puissance, stabilité, simplicité et élégance peuvent être cités ensemble dans la description d’un système unique. Le temps est venu pour que Mac OS X soit la prochaine étape de l’évolution des systèmes d’exploitation UNIX.

Ce document aide les développeurs à porter leurs applications UNIX vers Mac OS X. Il fournit les informations nécessaires à la compréhension du système. Il aborde quelques-uns des choix conceptuels et fournit une liste des principaux sujets à prendre en considération au moment du portage d’applications UNIX vers Mac OS X, ainsi que des discussions s’y rapportant. Il met aussi en évidence des fonctionnalités de Mac OS X qui ne sont pas disponibles dans des applications UNIX traditionnelles que vous pouvez ajouter à vos applications conevrties. Ce document est une vue d’ensemble, pas un tutoriel. Sous bien des aspects, c’est le compagnon idéal à l’ouvrage plus complet : “Inside Mac OS X: System Overview“, mais de manière plus orientée vers les développeurs UNIX.

A qui s’adresse ce Document ?

Ce document est conçu pour être lu par des développeurs effectuant le portage d’une application UNIX vers Mac OS X. De manière plus spécifique, il est à destination des développeurs UNIX qui n’ont pas d’expérience en développement sur Macintosh. Il aide à répondre aux questions générales relatives à la plate-forme dans son ensemble toout comme aux questions spécifiques relatives au portage d’une application UNIX sur la plate-forme Mac OS X. Il suppose que vous êtes à l’aise avec tous les aspects de la programmation, de l’écriture de code à l’utilisation des outils et techniques UNIX traditionnels.

Ce document n’est pas conçu pour des développeurs Java purs et dures. Une plate-forme Java 2, Edition Standard (J2SE) complète et robuste est implémentée dans Mac OS X. Si vous déjà une application en pure Java, elle doit fonctionner sous Mac OS X. Plus de détails à propos du développement en Java sont disponibles sur http://developer.apple.com/techpubs/java/.

Comment utiliser ce Document ?

Ce document est un premier arrêt pour les développeurs UNIX venant à Mac OS X. Il contient de nombreux liens vers des documentations plus détaillées. Certains détails spécifiques sont couverts ici uniquement dans le cas où ils ne le seraient pas de manière adéquate dans d’autres documentations.

Pour utiliser ce document avec efficacité, lisez d’abord Le chapitre 2, “Ce que vous devez savoir sur Mac OS X”, pour prendre connaissance des notions de base de la plate-forme Mac OS X et de certaines informations de haut niveau dont vous aurez besoin pour débuter votre portage. Si vous avez déjà une application construite sur une autre plate-forme UNIX, Le chapitre 3, “Le portage de base”, vous aidera à trouver comment compiler votre code sur Mac OS X.

C’est là que la majorité du travail est de votre ressort. Vous devrez prendre des décisions applicables à l’Interface Graphique Utilisateur, au cas où, à implémenter dans votre application. Le chapitre 4, “Migration de l’interface utilisateur”, et plus spécifiquement “Choix d’un Environnement Graphique” vous aideront à prendre ces décisions.

Si vous souhaitez réécrire votre application pour tirer profit de la richesse des fonctionnalités de Mac OS X, reportez-vous au Chapitre 5, “Fonctions Supplémentaires”, vous y trouverez des exemples de fonctions disponibles sous Mac OS X.

Une fois que vous disposez d’une application complète, lisez Le chapitre 6, “Distribuer votre Application”, pour obtenir des informations sur la manière de distribuer votre application à vos utilisateurs.

Trouver plus d’informations

De la documentation développeur peut être trouvée sur le site Web de la documentation des développeurs d’Apple à l’adresse http://developer.apple.com/techpubs/. Ce site contient des manuels de référence, de conception et d’apprentissage sur les nombreuses facettes du développement sur Mac OS X. Le CD des Outils de Développement Mac OS X comprend une copie de la documentation développeur, qui est installée dans /Developer/Documentation. Les pages man(1) sont aussi incluses avec les Outils Développeur Mac OS X.

Apple Developer Connection (ADC) héberge un site Web plein d’informations utiles aux développeurs UNIX se destinant à Mac OS X, http://developer.apple.com/unix. ADC offre aussi une variété de niveaux d’adhésion pour vous aider dans vos développements. Ils vont de l’adhésion gratuite qui vous donne accès aux logiciels développeurs, aux adhésions payantes qui comprend le support des incidents tout comme la possibilité d’obtenir les pré-versions des logiciels. Plus de détails sur http://developer.apple.com/membership/.

Une fois par an, en Mai, Apple héberge la Worldwide Developers Conference (WWDC - Conférence Mondiale des Développeurs) à San Jose, California. Cela représente une source d’une valeur extrème pour les développeurs essayant d’avoir une vue générale de Mac OS X ou voulant obtenir des détails spécifiques sur des technologies particulières. Plus d’informations sur la WWDC sur le site Web de l’ADC.

Apple héberge un grand nombre de listes de diffusion publiques. Elles sont disponibles sur http://lists.apple.com. La liste “unix-porting” est vivement recommandée. Les listes “darwin-development” et “darwinos-users” apporte beaucoup d’aides mais sont moins portées sur le portage.

En plus des ressources propres à Apple, beaucoup de ressources externes existent. Nous vous recommandons deux sites Web (anglais) : O’Reilly’s Mac DevCenter, et StepWise. (NdT : Et bien entendu Project:Omega !).

Ce que vous devez savoir sur Mac OS X

Le but de ce chapitre est de vous prodiguer des informations essentielles sur Mac OS X. Il commence par de brefs propos sur sa lignée puis il explique les différences qui existent entre Darwin et Mac OS X. Il conclut enfin en relatant des bénéfices à tirer d’un portage d’application vers Mac OS X et des devoirs qui en incombent.

L’Arbre Familiale

Bien que ce document couvre les concepts de base du portage d’applications UNIX vers Mac OS X, il n’a pas vocation à être exhaustif. Cette section est fournie dans le but de vous indiquer où chercher de plus amples documentations en schématisant la manière dont Mac OS X a été conçu. En savoir un peu sur la lignée de Mac OS X vous aidera à trouver plus de ressources au fur et à mesure que le besoin se fera sentir.

BSD

Une partie de l’histoire de Mac OS X remonte à l’UNIX BSD (Berkeley Software Distributions) du début des années soixante-dix. Plus spécifiquement, il est basé sur BSD 4.4 Lite. D’un point de vue système, une grande partie des décisions conceptuelles sont prises de manière à s’aligner sur les systèmes UNIX de type BSD. Beaucoup de librairies découlent de NetBSD (http://www.netbsd.org/), tandis que beaucoup d’utilitaires proviennent de FreeBSD (http://www.freebsd.org/). Pour les développements futurs, Mac OS X a adopté FreeBSD en tant que base de référence des technologies BSD. Le travail se poursuit pour mieux synchroniser tous les outils BSD avec la branche des FreeBSD stables.

Mach

Bien que Mac OS X doive créditer BSD pour les couches de bas niveau du système d’exploitation, Mac OS X doit aussi beaucoup à Mach. Le noyau est fortement influencé dans sa philosophie conceptuelle par le projet Mac de Carnegie Mellon. Le noyau n’est cependant pas une pure implémentation d’un micro-noyau puique l’espace d’adressage est partagé avec les traitements BSD. Pour plus de détails sur le noyau et les distinctions entre Mach et BSD, reportez-vous à la section “Le Noyau“.

NEXTSTEP

Pour bien comprendre ce qui fait battre le coeur de Mac OS X, il est important de reconnaître les influences de NEXTSTEP et OPENSTEP dans sa lignée. L’acquisition par Apple de NeXT en 1997 a été une étape essentielle dans la réalisation de Mac OS X. Beaucoup des parties de Mac OS X qui revêtent un intérêt pour les développeurs UNIX sont des améliorations et des ramifications des technologies présentes dans NEXTSTEP. Du “Système de fichiers” au “Format Executable”, et des API de haut niveau “Cocoa” au “Noyau” lui-même, il est très évident que Mac OS X est un descendant de NEXTSTEP.

Anciennes versions de Mac OS

Bien qu’il partage le même nom que les versions précédentes de Mac OS, Mac OS X est fondamentalement un nouveau système d’exploitation. Cela ne veut pas dire que tout ce qui s’est passé dans le passé est à oublier. Mac OS X comprend toujours beaucoup de fonctionnalités de Mac OS 9. Bien que votre portage initial ne soit pas amené à utiliser quelconque des fonctionnalités de Mac OS 9, il se peut qu’au fur et à mesure que vous améliorerez votre application, vous tiriez profit de quelques fonctions mises à dispotision par des technologies telles que ColorSync ou les API Carbon. Mac OS 9 est aussi la source de beaucoup de technologies utilisées dans Mac OS X.

Mac OS X et Darwin

Le mot Darwin est souvent utilisé en guise de référence à Mac OS X. En fait, dans certains milieux, Mac OS X est rarement mentionné. Il est important de comprendre les différences entre eux — ce qu’il y a en commun et ce qui les sépare.

Darwin est la base fondamentale du système d’exploitation Mac OS X. Bien qu’il puisse être un système d’exploitation indépendant à lui tout seul, il n’inclut qu’une partie des fonctionnalités disponibles dans Mac OS X. Figure 2-1 montre comment Darwin se rapporte à Mac OS X.

Figure 2-1 Les relations de Darwin avec Mac OS X

C’est un projet open source dont le code est disponible sur http://www.opensource.apple.com/. Cela vous permet d’avoir accès en tant que développeur aux fondations de Mac OS X. Son ouverture vous permet aussi de soumettre des changements dont vous pensez qu’ils devraient être propagés dans Mac OS X dans sa globalité. Darwin a été publié sous forme de projet séparé tournant sur des ordinateurs Macintosh basés sur PowerPC et sur des ordinateurs compatibles x86. Bien qu’il puisse être considéré de plein droit comme un système d’exploitation, de nombreux choix de conception fondamentale ont été gouvernés par le fait qu’il soit incorporé à Mac OS X. Lors du portage de vos applications vers cette plate-forme, vous devrez viser Mac OS X version 10.1 (Darwin 5.1) ou ultérieurs.

Mac OS X en lui-même n’est pas un projet open source. Comme illustré Figure 2-1, il y a beaucoup de parties de Mac OS X qui ne sont pas incluses dans les composants Darwin open source. Cela met en évidence le besoin de choisir où vous allez intégrer votre application dans Mac OS X. Si votre outil est à ligne de commande (ou comporte un module utile à ligne de commande), vous pouvez, bien sûr, porter votre application en tant qu’outil ou service à ligne de commande, ce qui est en général pas très compliqué. De cette manière vous tirerez un léger profit de par le fait que cela est maintenant disponible aux utilisateurs Mac OS X. Cependant, vous ne pourrez pas le commercialiser à tous les utilisateurs Mac OS X puisque beaucoup d’entre eux ne savent même pas comment à la ligne de commande sur leur ordinateur. Il est important de se souvenir qu’un portage vers la ligne de commande n’est qu’une première étape dans le processus qui doit amener votre application à tirer pleinement profit des avantages de Mac OS X. L’étape suivante serait de fournir une interface graphique (GUI). “Migration de l’Interface Utilisateur” vous donne plus d’informations sur la manière de décider quelle sera l’une des nombreuses API à utiliser.

Si ajoutez une nouvelle interface graphique à une application à ligne de commande et désirez tirer profit des meilleures avantages de Mac OS X, vous voudrez probablement utiliser les API Cocoa. Dans certains cas, vous voudrez peut être utiliser une API différente pour des raisons de compatibilité multi-plateforme par exemple. Si vous décidez d’utiliser une API nominative telle que X111R6, pour donner une interface utilisateur à vos applications Mac OS X, il est important de se rappeler que les utilisateurs et les développeurs ayant l’expérience d’UNIX seraient peut être parfaitement heureux qu’elles ne tournent que sur Mac OS X. Les utilisateurs traditionnels Macintosh, cependant, mettront de côté une application dotée d’une interface UNIX traditionnelle pour en trouver une avec une interface plus moderne et mieux intégrée. A vous de décider si vous ciblez un portage direct vers la couche DARWIN ou une transformation plus robuste de votre application pour tirer partie d’autres technologies Mac OS X comme les frameworks Cocoa.

Ce que les utilisateurs Macintosh attendent

En portant votre application vers Mac OS X, vous pénétrez dans un monde où une grande place est donnée aux interactions utilisateurs. Cela vous apporte beaucoup d’opportunités et d’avantages en tant que développeur, mais cela vous donne aussi quelques responsabilités.

Avantages

Les utilisateurs Macintosh sont connus pour leur loyauté, mais cette loyauté n’est pas aveugle. Elle est basée sur des années de confiance développées entre les développeurs et les utilisateurs Mac. Ils ont la volonté de dépenser leur argent pour de grandes applications parce qu’ils savent qu’Apple ambitionne de leur donner un environnement utilisateur de haute qualité. Les développeurs Apple sont connus pour concevoir de belles applications pour cet environnement. Le portage d’applications UNIX vers Mac OS X peut être très profitable s’il est effectué correctement, un investissement à la fois en amour-propre et en affaire. Les applications Macintosh bien conçues des années pasées sont les standards d’aujourd’hui. PowerPoint, PhotoShop, Illustrator et Excel sont toutes des applications qui ont d’abord fait leurs armes sur Macintosh. Il est temps maintenant de gagner le coeur des utilisateurs Mac avec les prochaines grandes applications. En un mot, des millions d’utilisateurs potentiellement loyaux.

Ce n’est pas qu’une histoire de business cependant. Apple est reconnu pour son engagement envers l’éducation depuis de nombreuses années. Mac OS X cible le marché de l’éducation pour les développeurs et constitue une plateforme idéale pour l’enseignement. Avec ses technologies basées sur les standards et celles développées en interne, vous avez une plateforme taillée pour une utilisation en déploiement et développement d’applications éducatives.

Mac OS X apporte aussi des avantages en environnement de développement. Apple respecte d’abord les standards puis elle ajoute ce petit plus qui les rendent meilleurs sur Mac. Vous avez accès à la plupart des environnements et outils de développement que vous trouvez sur les autres plateformes, comme Java, OpenGL, les librairies POSIX et la pile TCP/IP BSD, mais vous disposez aussi en intégré d’un serveur Web Apache sur chaque ordinateur, de l’environnement de développement orienté objet Cocoa, d’un système d’affichage basé sur le format, de Quartz, de la compatibilité Kerberos, de QuickTime, d’une implémentation audio dynamique au niveau du noyau et d’une suite d’outils développeurs de classe mondiale. En ajoutant un front-end Mac OS X natif à vos applications, vous pouvez réaliser une nouvelle plateforme de déploiement bon marché avec un minimum de développements supplémentaires.

Mac OS X apporte une valeur incroyable à vous et à vos clients sur un système d’exploitation basé sur des standards.

Responsabilités

Les avantages s’accompagnent de responsabilités. Si vous avez décidé de construire une application dotée de toutes les fonctionnalités Mac OS X, voici quelques conseils simples mais essentiels à garder en mémoire.

Un utilisateur Mac OS X ne devrait jamais avoir à recourir à la ligne de commande pour effectuer des tâches dans une application dotée d’une interface graphique. Ceci est spécialement important à se rappeler puisque l’environnement BSD utilisateur peut ne pas être installé sur un système utilisateur. Les librairies et l’environnement “kernel” sont bien sûr là par défaut, mais pas les outils.

Si vous devez faire des choix en matière de conception graphique, vous avez besoin de vous familiariser avec les Directives d’Interface Humaine Aqua qui sont disponibles sur le site Web des développeurs Apple. Ils représentent les standards que les utilisateurs Mac s’attendent à trouver dans leurs applications. Des applications Apple et de tierce partie qui se comportent correctement donne au Mac sa réputation de meilleure interface de la planète.

Ces responsabilités poussent à réaliser un excellent produit d’un point de vue utilisateur. Mac OS X vous apporte les outils qui vous pemettront de faire briller votre application.

Le Portage de Base

Un développeur UNIX aguerrit reconnaît que même si deux systèmes d’exploitations peuvent sembler similaires, il y a toujours des détails qui les séparent l’un de l’autre. Ce chapitre met en évidence quelques zones clés auxquelles vous devriez faire attention lorsque vous en arriverez à compiler votre code pour Mac OS X. Des détails sur les options de compilation y seront notés, ainsi que des conseils sur la manière de linker certaines parties de votre sous Mac OS X. La plupart de ces sujets sont abordés de manière plus détaillée dans d’autres ressources comme indiqué.

Préparation

Avant de commencer le portage basique de votre code vers Mac OS X, vous devez vous assurez que vous avez les outils nécessaires à chaque tâche. Vous devez aussi faire attention à ce qui est disponible par défaut et à ce qui ne l’est pas.

Les Outils Développeurs Mac OS X

Apple fournit gratuitement une suite d’outils de développement spécifiques et de première classe. Bien qu’il se peut qu’ils ne soient pas installés sur votre ordinateur, ils sont en général distribués avec les CD de Mac OS X. Ils sont aussi disponibles en ligne sur le site Web de l’Apple Developer Connection (ADC). Vous aurez besoin d’un compte ADC pour télécharger les outils de développement. Des comptes gratuits sont disponibles pour ceux qui ne souhaitent qu’avoir accès à ces outils. C’est une bonne idée de vérifier le site Web de l’ADC pour y détecter les versions les plus récentes des outils de développement puisque les mises à jour y sont publiées souvent.

Après avoir installé les outils de développement Mac OS X, vous aurez une sélection de nouveaux outils vous permettant de tirer prodit de :

A l’intérieur de /Developer/Tools vous trouverez beaucoup d’outils de développement spécifiques Mac OS X. La documentation est fournie sous la forme de pages man.
/usr/bin contient maintenant plus d’outils à ligne de commande qu’il n’en était livré par le package BSD seul, notamment cc et gdb. /usr/bin/cc correspond à gcc 3.1 dans la version 10.2 de Mac OS X, mais gcc 2.9.52 est aussi disponible. Se reporter à Choix d’un compilateur pour plus d’informations.
/Developer/Applications contient un grand assortiment d’outils et d’utilitaires graphiques. Les principaux sont :

La documentation de ces outils est disponible dans Developer Help Center du menu Help de Project Builder et en ligne à l’adresse suivante : http://developer.apple.com/techpubs/macosx/DeveloperTools/devtools.html.

Installer des Outils de Développement Open Source

Du fait que Mac OS X comporte un noyau BSD, vous avez accès aux nombreux outils open source, tels que les outils GNU, auxquels vous êtes déjà habitués. Apple fournit une sélection basique des outils les plus communs avec Mac OS X sous forme d’installation spéciale, il faut donc s’assurer, avant d’utiliser Mac OS X comme plateforme de développement, que le Sous-système BSD est installé. Vous pouvez le vérifier en recherchant la présence du reçu relatif au package BSD, BSD.pkg, dans la répertoire /Library/Receipts. S’il n’ est pas présent sur votre système ou si vous installez Mac OS X pour la première fois, assurez-vous que ce package soit installé :

Insérez votre CD Mac OS X.
Double-cliquez sur l’application Install Mac OS X située dans la dossier Welcome to Mac OS X.
Dans la fenêtre qui s’ouvre, cliquez sur le bouton Redémarrez.
Une fois que votre ordinateur est redémarré, suivez les instructions juqu’à ce que vous arriviez à la phase Type d’Installation. (Ceci est indiqué sur la partie gauche de la fenêtre d’installation).
Cliquez sur le bouton Personnaliser.
Sélectionnez Sous-système BSD.
Procédez à l’installation en suivant les instructions.

Une fois que le sous-système BSD est installé, un oeil jeté dans /bin et /usr/bin devrait révéler un environnement familier.

Le package Outils Développeur Mac OS X apporte des outils supplémentaires que vous aurez besoin d’installer pour compléter votre environnement de développement. Reportez-vous au paragraphe “Les Outils Développeurs Mac OS X”. Ils ne font pas partie de l’installation par défaut, mais sont essentiels puisqu’ils comportent quelques-uns des outils les plus importants tels que le compilateur (gcc) et le debogueur (gdb).

Construire des Projets Conformes avec Project Builder

Bien que Project Builder garde trace des réglages de construction dans ses propres fichiers de préférences afin de mémoriser des informations qui vont au-delà de ce qui serait normalement maintenu dans un fichier makefile, cela ne veut pas dire que Project Builder ne puisse pas communiquer avec les fichiers makefiles conformes de vos projets. Si vous voulez utiliser Project Builder pour développer sur Mac OS X, les lignes suivantes vous donnent un bref aperçu de la manière d’incorporer un fichier makefile conforme au sein d’un projet Project Builder :

Ouvrez Project Builder.
Choisissez New Project dans le menu File.
Sélectionnez le type de projet que vous ciblez. Si vous ne souhaitez construire qu’une application, sélectionnez quelque chose dans le genre Cocoa Application. Si vous ne souhaitez que bâtir qu’un outil à ligne de commande, sélectionnez un des outils, Standard Tool peut être.
Suivez les instructions et sauvegardez votre projet. Un nouveau projet du type sélectionné est ouvert.
Dans le menu Project, choisissez New Target.
Sélectionnez Legacy Makefile.
Suivez les instructions pour nommer cette cible. Une fois que vous avez effectué ceci, une icône de cible avec le nom que vous lui avez attribué doit apparaître dans le panneau Targets de la fenêtre ouverte de Project Builder.
Sélectionnez cette nouvelle cible.
Le panneau informations change maintenant d’aspect pour refléter les informations de construction de cette cible. Modifiez ces réglages pour inclure votre makefile et tout autres réglages dont vous auriez besoin. Par exemple, dans le panneau Custom Build Command, vous pourriez changer Build Tool de /usr/bin/gnumake en /usr/bin/bsdmake. Plus d’informations sur ces champs sont disponibles dans l’Aide de Project Builder.
Une fois que vous êtes prêt à construire votre projet, cliquez sur le bouton Build and Run situé dans la barre d’outils, sélectionnez Build and Run dans le menu Build, ou pressez simplement Command-R.

Cela devrait pour permettre finalement à porter votre application dans l’environnement natif de construction de Mac OS X.

A propos de l’environnement de fenêtrage

Avant même de compiler votre application votre application sous Mac OS X, vous devriez faire attention au fait que le sous-système de fenêtrage et d’affichage de Mac OS X, Quartz, est basé sur le Portable Document Format (PDF). Quartz consiste en un léger serveur de fenêtre et en une librairie de rendu grapique pour les formes en 2D. Les serveur de fenêtre offre des fonctions de couleurs et des profondeurs de pixel indépendamment du périphérique, de compositions de couches, et de fenêtres à tampon. Le modèle de rendu est basé sur le format PDF. Quartz n’est pas une implémentation du système X Window. Si vous avez vraiment besoin d’une implémentation X11R6, vous pouvez en installer une simplement. Si votre application utilise le système X Window, vous devrez soit porter l’interface utilisateur vers un environnement natif Mac OS X ou fournir une implémentation du système X Window avec votre application. Ce qu’il faut prendre en considération au moment de prendre cette décision tout comme les informations relatives aux environnements graphiques disponibles peuvent être trouvées au paragraphe “Migration de l’Interface Utilisateur”.

Compiler votre Code

Maintenant que les pièces de base sont en place, il est temps de construire votre application. Cette section aborde les problèmes les plus fréquents que vous rencontrerez lors du portage de votre application UNIX vers Mac OS X.

GNU Autoconf

Si vous essayez de porter un utilitaire existant à ligne de commande qui utilise GNU Autoconf, vous vous apercevrez que la plupart des utilitaires fonctionnent ; lancez juste configure et make comme vous le feriez sur d’autres systèmes UNIX.

Si Autoconf échoue parce qu’il ne comprend pas l’architecture, essayez de remplacer les fichiers config.sub et config.guess du projet avec ceux disponibles dans /usr/share/automake-1.6. Si vous distribuez des applications qui utilisent Autoconf, introduisez s’il vous plait une version à jour de config.sub et de config.guess de façon à ce que les utilisateurs Mac OS X n’aient rien à faire pour rendre utilisable votre projet.

Vous aurez aussi peut-être besoin de lancer /usr/bin/autoconf sur votre projet avant qu’il ne fonctionne. Mac OS X comprend Autoconf dans le package des outils BSD. Outre ces notions basiques, si le projet ne se contruit pas, vous aurez peut-être besoin de modifier votre makefile en respectant les astuces fournies dans les sections suivantes. Après ça, une réécriture plus intense sera peut-être nécessaire.

Choix d’un Compilateur

Mac OS X 10.2 comprend deux compilateurs différents et leur chaîne d’outils correspondante. Le compilateur par défaut est basé sur gcc 3.1. En plus, un compilateur basé sur gcc 2.95.2 est fourni.

Vous devriez toujours compiler vos logiciels avec gcc 3.1, puisque les chaînes d’outils futures seront basées sur gcc version 3.1 et ultérieures. Cependant, puisque gcc 3.1 est une chaîne d’outils relativement récente, vous y trouverez peut-être des bogues qui empêchetont la compilation de certains programmes.

Si vous vous êtes confronté à un problème qui semble être du à un bogue du compilateur, la commande sudo gcc_select 2 changera le compilateur par défaut en gcc 2.95.2. Vous pourrez le changer de nouveau à tout moment en tapant sudo gcc_select 3. Cela devra être considéré en dernier recours, cependant. Si possible, vous devrez essayer gcc 3.1 pour compiler votre application en spécifiant différentes options de compilation.

Option de compilateur

Lorsque vous contruisez votre projet sur Mac OS X, le fait de fournir ou de modifier les flags compilateur de certaines options clés facilitent les choses pour la plupart des programmes. Ils sont en général spécifiés par l’argument CFLAGS dans votre makefile. Les flags les plus communs à ajouter sont les suivants :

-no-cpp-precomp

Mac OS X utilise des en-têtes pré-compilées pour accélérer la compilation des codes source C++ et Objective-C. Par défaut, cette utilisation est effectuée par le préprocesseur Mac OS X et non le préprocesseur GNU C. Sachant que beaucoup de projets open source sont écrits avec les extensions du préprocesseur GNU C, que le préprocesseur Mac OS X n’implémente pas, vous pouvez désactiver le préprocesseur avec le flag -no-cpp-precomp. Cela vous donnera le comportement du préprocesseur GNU. Dans pas mal de cas, lorsque des messages d’erreur se rapportent aux en-têtes précompilées, c’est par ça qu’il faut commencer.

Note: Dans les versions précédentes de Mac OS X, -traditional-cpp était suggéré. Bien que ce flag fonctionne toujours dans la version actuelle, le flag -no-cpp-precomp plus approprié devrait être utilisé à la place.

-fno-rtti: Désactive les informations de type run-time. Le support de RTTI dans gcc 3.1 est depuis longtemps bogué et cette option devrait vous permettre de contourner ces bogues dans certaines circonstance.

-shared: Utilisez ce flag pour générer des librairies partagées sur Mac OS X. Les libraries partagées peuvent être différentes de celles que vous avez l’habitude de voir sur d’autres plateformes. Se reporter à “Librariries Dynamiques et Plug-ins”.

-flat_namespace (dans LDFLAGS): Par défaut, Mac OS X construit les librairies et les applications avec un espace-nom à deux niveaux où les références vers les librairies dynamiques sont traitées comme des définitions, contenues dans une librairie dynamique spécifique, lorsque l’image est construite. Ce flag peut être utilisé pour changer ce comportement. L’espace-nom à deux niveaux est abordé au paragraphe : Espace de nommage à deux niveaux.

-bundle (dans LDFLAGS): Produit un fichier au format “bundle” Mach-O, qui est utilisé pour la création de plug-ins chargeables. Se reporter à la page man ld(1) pour plus de détails sur ce flag.

-bundle_loader exécutable (dans LDFLAGS): Lors de la construction d’un plug-in, il vous permet de spécifier l’exécutable qui sera amené éventuellement à le charger. Les symboles indéfinis de ce bundle sont vérifiés par rapport à l’exécutable spécifié comme s’il s’agissait d’une autre librairie dynamique, s’assurant ainsi que le bundle sera chargeable sans qu’il y ait de symboles manquants.

-framework framework (dans LDFLAGS): Ce flag a pour conséquence de lier l’exécutable en cours de construction au framework spécifié.

Beaucoup plus de détails sur le compilateur en général peuvent être trouvés sur http://developer.apple.com/techpubs/macosx/ReleaseNotes/Compiler.html tout autant que dans la section GNU C de http://developer.apple.com/techpubs/macosx/DeveloperTools/devtools.html.

Espace de nommage à deux niveaux

Par défaut, Mac OS X construit des librairies et des applications avec un espace de nommage (ensemble de noms communément distribués dans lequel tous les noms sont uniques) à deux niveaux. L’idée de base est : quand une librairie est compilée, les références à d’autres librairies dynamiques sont résolues par une définition située dans un librairie dynamique spécifique.

La conception de cet espace de nommage à deux niveaux comporte beaucoup d’avantages pour les applications carbon. Cependant, elle peut causer des problèmes pour nombre d’applications UNIX traditionnelles si elles ont été conçues pour fonctionner dans un environnement à espace de nommage plat.

Par exemple, imaginez qu’une librairie, appelée libfoo, utilise une autre librairie, libbar pour son implémentation. Maintenant imaginez qu’une application souhaite surpasser l’utilisation de libbar par une version compressée, appelée libzbar. Puisque libfoo a été linkée avec libbar au moment de la compilation, cela n’est pas possible sans recompiler libfoo.

Pour permettre à une application de surpasser les références faites par libfoo à libbar, vous utiliserez l’option -flat_namespace. La page man ld(1) comporte plus de détails sur cette option. L’espace de nommage à deux niveaux est abordé à l’adresse : http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html.

Si vous écrivez des librairies en partant de zéro, il peut être intéressant de considérer l’espace de nommage à deux niveaux dans votre conception. Si vous vous attendez à ce que quelqu’un puisse avoir envie de surpasser l’utilisation que fait votre librairie d’une autre librairie, vous devrez alors placer une routine qui prendra comme arguments des pointeurs vers la seconde librairie puis utiliser ces pointeurs pour les appels au lieu d’appeler directement la seconde librairie.

Autrement, vous pouvez utiliser une architecture à plug-in dans laquelle les appels vers les librairies externes sont effectués par un plug-in qui peut aisément être remplacé par un plug-in différent pour une librairie externe différente. Se reporter à “Librairies Dynamiques et Plug-ins” pour plus d’informations.

Pour la majeure partie, cependant, sauf si vous concevez une librairie en partant de zéro, il n’est pas pratique d’éviter l’utilisation de -flat_namespace si vous devez surpasser des références faites dans une librairie vers une autre librairie.

Format Exécutable

Le seul format exécutable que le noyau Mac OS X comprenne est le format Mach-O. Quelques outils de liaison sont fournis pour les formats d’exécutables de l’environnement Classic, mais Mach-O est le format natif. Il est très différent du format ELF (Executable and Linking Format) couramment utilisé. Pour plus de détails sur Mach-O, reportez-vous à Inside Mac OS X: Mach-O Runtime Architecture, disponible à l’adresse : http://developer.apple.com/techpubs/macosx/DeveloperTools/devtools.html.

Librairies Dynamiques et Plug-ins

Mac OS X fait un usage intensif de code “linké” dynamiquement. A l’inverse d’autres formats binaires tels que ELF et xcoff, Mach-O traite les plug-ins de manière différente que les librairies partagées.

Les librairies que vous avez l’habitude rencontrer sur d’autres systèmes UNIX peuvent ne pas être installées sur Mac OS X aux mêmes endroits. Cette différence est principalement due à la présence d’un seul framework chargeable dynamiquement, libSystem, qui contient les fonctionnalités principales du système. Cet unique module fournit l’environnement d’exécution C standard, les routines d’entrée/sortie, les librairies mathématiques et la plupart des fonctionnalités nomales requises par les applications à ligne de commande et par les services réseau. Ce module comprend des fonctions que vous vous attendriez à trouver dans libc, libm, les services RPC et dans le resolver. libSystem est “linkée” automatiquement de telle façon que vous n’avez pas à l’ajouter explicitement à la ligne de compilation.

Il est important de noter que Mac OS X ne supporte pas le concept de “weak linking” comme on peut le trouver dans des systèmes genre GNU/Linux. Si vous surpasser un symbole, vous devez alors surpasser tous les symboles du fichier objet.

Si vous devez charger dynamiquement du code avec Mac OS X, utilisez les fonctions NSObjectFileImage spécifiées dans /usr/include/mach-o/dyld.h et dans la page man NSObjectFileImage(3). NSObjectFileImage fournit les fonctionnalités auxquelles vous devriez être habitués que l’on peut trouver dans les routines dl* sur d’autres systèmes. Autrement, vous pouvez utiliser les API CFPlugIn ou CFBundle, contenues dans la CoreFoundation.

Pour un portage rapide mais bâclé, une compatibilité proche de dlopen et du reste de la famille existe dans de nombreuses distributions d’outils open source. Cependant, ces implémentations ne sont pas des équivallents pleinement fonctionnels des fonctions de la famille dlopen, et ne sont ne général pas recommandés à part lors portages initiaux d’application.

Les pages man ld(1) et dyld(1) donnent des détails plus spécifiques sur l’implémentation du “linkeur” dynamique.

Bundles

Les bundles sont utilisés partout dans le système Mac OS X. Malgré le fait que vous puissiez ne pas être habitué aux bundles, ils ne doivent pas être redoutés. Les bundles ne sont que des répertoires qui contiennent le code exécutable et les ressources logiciel associées à ce code, le tout sous la forme d’un package discret. Les bundles sont abordés en détail dans Inside Mac OS X: System Overview.

Bundles Applicatifs

Les bundles applicatif sont des bundles spéciaux qui s’affichent dans le Finder sous la forme d’une seule entité. Le fait qu’il ne soit représenté que par un seul élément autorise l’utilisateur à double-cliquer dessus pour lancer l’application et toutes ses ressources. Si vous construisez des applications Mac OS X, vous devrez faire des bundles applicatifs. Project Builder les construit par défaut si vous sélectionnez un des types de projet applicatif. Pour plus d’informations sur les bundles applicatifs, reportez-vouos à Inside Mac OS X: System Overview.

Frameworks

Un framework est un type de bundle qui englobe une librairie partagée avec les ressources que cette librairie requiert. En fonction de la librairie, cela peut comprendre des fichiers en-têtes, des images et des documentations de référence. Si vous essayez de maintenir une compatibilité multi-plateforme, vous ne souhaiterez peut être pas les utilisez vous même, mais vous devrez prendre conscience de leur présence puisque vous serez peut être amené à établir des liens avec. Par exemple, vous aurez peut être à établir un lien avec le framework Core Foundation. Sachant qu’un framework n’est qu’une forme de bundle, vous effectuerez ceci en liant /System/Library/Frameworks/CoreFoundation.framework avec le flag -framework. Plus de détails sur les frameworks se trouvent dans Inside Mac OS X: System Overview.

Migration de l’Interface Utilisateur

Mac OS X offre beaucoup d’options pour transformer vos applications dotées d’une interface graphique en partant d’un code source UNIX pour arriver à un code natif Mac OS X, ou même pour envelopper des outils ou utilitaires existants à ligne de commande avec un front end graphique, les rendant ainsi accessibles aux utilisateurs qui ne veulent pas entendre parler de ligne de commande.

Choix d’un Environnement Graphique

Pour choisir votre environnement graphique lors d’un portage d’une application UNIX vers Mac OS X, vous devrez répondre aux questions posées dans les sections suivantes :

“Quel type d’application allez vous porter ?”
“Jusqu’à quel point doit elle s’intégrer à Mac OS X ?”
“Est-ce que votre application nécessite une des fonctionnalités multi-plateforme ?”

Ces questions devraient toute être prises en considération au moment de peser le coût et les avantages de chaque environnement. Mac OS X offre une grande variété de kits d’outils et d’API multi-plateformes avec lesquels travailler, il est donc important de prendre celui qui vous correspond le mieux.

Quel type d’application allez vous porter ?

Allez-vous porter un code existant vers Mac OS X, ou allez-vous ajouter de nouvelles fonctionnalités, telle qu’une interface graphique à une application à ligne de commande ? Evidemment, si vous disposez d’un code écrit avec une API particulière et que cette API est supportée sur Mac OS X, vous allez probablement souhaiter profiter de cette API pour toute application importante et complexe. Pour des applications simples, ou pour des application issues de l’ajout d’une interface graphique à un outil à ligne de commande, vous devez évaluer l’API à utiliser en fonction des réponses données à “Jusqu’à quel point doit elle s’intégrer à Mac OS X ?” et à “Est-ce que votre application nécessite une des fonctionnalités multi-plateforme ?”. Il est important de jauger les avantages et les inconvénients de chaque technologie listée dans le paragraphe s’y rapportant.

Jusqu’à quel point doit elle s’intégrer à Mac OS X ?

A quel marché destinez vous votre application ? Si vous la destinez à des utilisateurs UNIX traditionnels qui ne souhaitent que pouvoir lancer une application de séquencement de gènes, par exemple, aux côtés de Microsoft Office, il peut être alors suffisant de n’installer qu’un Système X Window sur leur ordinateur Mac. Vous ne porteriez alors que votre application à base de X11-R6 vers Mac OS X, laissant votre code comme il est en y apportant que de petits changements pour le compiler sur Mac OS X. Si vous commercialiser cette application, quelques clients seront peut-être contents d’en disposer sur leur plateforme. Cependant, si un produit concurent sort avec une interface native Mac OS X, les cllients seront tentés de l’acheter. Dans le domaine de l’industrie des sciences et des technologies, le fait de porter un code source vers Mac OS X n’est pas une prouesse en soi, mais le fait d’aller plus loin et faire en sorte que ce code soit accessible au travers d’une interface Mac OS X native s’en rapproche. Ce n’est pas un décision à prendre à la légère pour les codes source très importants, mais c’en est une qui peut prolonger ou stopper la carrière d’un produit. Les propos qui suivent devraient vous aider à prendre la bonne décision.

Est-ce que votre application nécessite une des fonctionnalités multi-plateforme ?

Si vous avez une application qui requiert des fonctionnalités multi-plateforme, Mac OS X garantit votre succès. Vous disposez de beaucoup d’options ; certaines sont integrées et embarquées dans chaque version du système — d’autres nécessitents l’installation de composants supplémentaires. La figure ci-dessous illustre les différences entre les API multi-plateformes natives et celles qui ne le sont pas.

Figure 4-1 Environnements graphiques

Vous pouvez voir que Mac OS X comprend certains standards dans ses API natives multi-plateforme : Java, OpenGL et QuickTime. Il y a aussi des implémentations commerciales et gratuites de certaines technologies UNIX. Si vous construisez une application multi-plateforme, vous devriez évaluer la plateforme que vous ciblez avec votre application et déterminer quelle API vous permet de porter votre application UNIX vers Mac OS X. Le tableau ci-dessous liste les plateformes sur lesquelles les technologies multi-plateformes de Mac OS X sont supportées.

Table 4-1 Platformes de technologies multi-platformes

API	Plateformes
OpenGL	Mac OS X, systèmes UNIX, Windows
Java	Mac OS X, systèmes UNIX, Windows
QuickTime	Mac OS X, Windows
Qt	Mac OS X (natif et X11), systèmes UNIX X Windows, Windows
Tcl/Tk	Mac OS X (natif et X11), systèmes UNIX, Windows
X11R6	Mac OS X, systèmes UNIX

Note : Bien que certaines technologies de ce tableau soient supportées sous Mac OS 9, cela n’est pas pris en compte ici car votre code UNIX ne peut tourner sous Mac OS 9.

Dans les sections qui suivent, une brève description de chacune de ces technologies que vous pourriez utiliser lors du portage de votre application UNIX vers Mac OS X vous sera donnée.

Cocoa, Java et Carbon

Mac OS X comprend trois environnements de développement natifs de haut niveau que vous pouvez utiliser pour l’interface graphique utilisateur de votre application : Cocoa, Java et Carbon. Ces environnements sont des environnements de développement complètement fonctionnels et vous pouvez vous en servir pour écrire des applications très complètes. Dans le contexte de ce document, ils sont présentés sous une approche d’utilisation en guise de front-end pour un back-end UNIX. Le fait d’écrire pour ces environnements vous permet de construire une application placée au-dessus de votre code source de base qui ne peut être distinguée des autres applications natives de Mac OS X. Les frameworks Java et Cocoa sont probablement les environnements à utiliser lors d’un portage vers Mac OS X, bien que les frameworks Carbon soient utilisés par quelques développeurs. Ils sont tous les trois détaillés dans les paragraphes qui suivent.

Figure 4-2 Technologies graphiques de haut niveau

Cocoa

Cocoa est un framework orienté-objet qui englobe la plupart des meilleures forces de Mac OS X. Il permet le développement et le déploiement rapide d’applications avec à la fois sa conception orientée objet et son intégration avec les outils de développement de Mac OS X. Cocoa est divisé en deux parties principales : Foundation et le Kit Application. Foundation fournit les classes fondamentales qui définissent les types et les ensembles de données ; il fournit aussi les classes pour accéder aux informations basiques du système telles que les dates et les ports de communication. Le Kit Application repose dessus en vous donnant les classes dont vous avez besoin pour implémenter des interfaces utilisateurs graphiques basées sur la détection d’évènements.

Le langage natif pour Cocoa est l’Objective-C, qui fournit des extensions orientées objet au C standard et à l’Objective-C++. Inside Mac OS X: The Objective-C Programming Language décrit la grammaire de l’Objective-C et présente les concepts qui se cachent derrière. Objective-C est supporté dans gcc 2.95 et 3. La plupart des API Cocoa sont aussi accessibles au travers de Java.

Des informations supplémentaires, y compris des exemples de codes, peuvent être trouvées à http://developer.apple.com/cocoa. La documentation Cocoa comprenant des tutoriels est disponible à http://developer.apple.com/techpubs/macosx/Cocoa/CocoaTopics.html.

NdT : Vous trouverez aussi beaucoup d’informations sur Cocoa et l’Objective-C dans nos tutoriels : La série Programmation Cocoa et Apprendre l’Objective-C (pdf).

Avantages du développement sous Cocoa

Environnement de développement rapide
Conception orientée objet du framework
Intégration excellente avec les outils développeurs de Mac OS X
Ensemble de fonctions très robustes
Peut tirer profit des codes existants C, C++, Objective-C et Java

Inconvénients du développement sous Cocoa

Pas de déploiement multi-plateforme
Nécessite d’apprendre l’Objective C ou l’Objective C++.

Exemple: Appeler le C ou le C++ avec Cocoa

Lorsque vous concevez une application sous Cocoa en partant de zéro, vous êtes dans un environnement orienté objet. Vous pouvez tirer profit de la nature orientée objet de Cocoa au moment de convertir du code existant. Vous pouvez utliser les frameworks Cocoa pour envelopper les fonctionnalités de codes C ou C++.

La langage Objective-C a été étendu pour comprendre le C++. Il est alors souvent appelé Objective-C++, mais les fonctionnalités restent basiquement les mêmes. Du fait que Cocoa comprenne l’Objective-C++, vous pouvez appeler du code C et C++ à partir de Cocoa. C’est un exemple de la manière dont vous pouvez tirer profit de vos codes existants lorsque vous ajoutez un front-end Macintosh. Un exemple est fourni ci-dessous pour illustrer comment Objective-C incorpore des fonctionnalités C, C++ et Objective-C++. Le listing 4-1 montre la classe principale de l’Objective-C.

Listing 4-1 main.m

#import <AppKit/AppKit.h>

int main(int argc, const char *argv[]) {
    return NSApplicationMain(argc, argv);
}

Cela provoque le démarrage de l’application au moment où l’utilisateur double-clique sur l’icône. Un appel est alors envoyé à l’objet HelloController par le fichier NIB, un fichier qui contient les informations relatives à l’interface. HelloController.m et HelloController.h suivent.

Listing 4-2 HelloController.m

#import "HelloController.h"

@implementation HelloController

- (void)doAbout:(id)sender
{
    NSRunAlertPanel(@"About",@"Welcome to Hello World!",@"OK",NULL,NULL);
}

- (IBAction)switchMessage:(id)sender
{
        int which=[sender selectedRow]+1;
        [helloButton setAction:NSSelectorFromString(
        [NSString  stringWithFormat:@"%@%d:",@"message",which])];
}

- (void)awakeFromNib
{
    [[helloButton window] makeKeyAndOrderFront:self];
}

@end

Listing 4-3 HelloController.h

#import <AppKit/AppKit.h>

@interface HelloController : NSObject
{
    id helloButton;
    id messageRadio;
}
- (void)doAbout:(id)sender;
- (void)switchMessage:(id)sender;
@end

La communication entre le code C, C++ et Objective-C est gérée comme illustré au Listing 4-4. Le fichier d’en-tête SayHello.h est montré dans le Listing 4-5.

Listing 4-4 SayHello.mm

#import "SayHello.h"
#include "FooClass.h"
#include <Carbon/Carbon.h>

@implementation SayHello

- (void)message1:(id)sender
{
    NSRunAlertPanel(@"Regular Obj-C from Obj-C",@"Hello, World! This is a
    regular  old NSRunAlertPanel call in Cocoa!",@"OK",NULL,NULL);
}

- (void)message2:(id)sender
{
    int howMany;
    NSString *theAnswer;
    Foo* myCPlusPlusObj;
    myCPlusPlusObj=new Foo();
    howMany=myCPlusPlusObj->getVariable();
    delete myCPlusPlusObj;
    theAnswer=[NSString stringWithFormat:@"Hello, World! When our C++ object
    is  queried, it tells us that the number is %i!",howMany];
    NSRunAlertPanel(@"C++ from Obj-C",theAnswer,@"OK",NULL,NULL);
}

- (void)message3:(id)sender
{
    Alert(128,NULL); //This calls into Carbon
}

@end

Listing 4-5 SayHello.h

#import <AppKit/AppKit.h>

@interface SayHello : NSObject
{
}

- (void)message1:(id)sender;
- (void)message2:(id)sender;
- (void)message3:(id)sender;
@end

La classe C++ qui est incorporée par ces appels Cocoa est montrée dans le Listing 4-6. Le fichier d’en-tête, FooClass.h, est montré dans le Listing 4-7.

Listing 4-6 FooClass.cpp

#include "FooClass.h"
Foo::Foo()
{
 variable=3;
}

int Foo::getVariable()
{
 return variable;
}

Listing 4-7 FooClass.h

class Foo {
public:
    Foo();
    int getVariable();
    void * objCObject;
private:
    int variable;
};

Java

Mac OS X comprend une implémentation compète de Java 2 Platform Standard Edition (J2SE) avec le JDK 1.3.1. Le développement en Java pur fonctionne sur Mac OS comme il le ferait sur toute autre plateforme. Plus d’informations sur le développement Java sur Mac OS X peut être trouvé en ligne sur http://developer.apple.com/java.

NdT : Vous trouverez aussi beaucoup d’informations sur Java dans nos tutoriels : Le langage Java.

Avantages du développement en Java

Installé par défaut sur Mac OS X
Le éléments Swing sont affichés avec l’apparence et le comportement natif Aqua de Mac OS X
Déploiement multi-plateforme

Inconvénients du développement en Java

Peut ne pas être aussi rapide qu’une implémentation native pure
Complexités de communication entre deux langages différents si votre code est basé sur du C
Accès limités au matériel et capacités spécifiques à l’OS

Carbon

Carbon est un environnement conçu pour porter des applications Mac OS existantes vers Mac OS X. C’est un environnement très robuste mais il n’a pas été conçu initialement pour tirer pleinement profit de Mac OS X. Vous pouvez porter vos applications UNIX vers Mac OS X en utilisant les API Carbonn mais compte tenu qu’il y a des fonctionnalités spécifiques à Carbon vous devriez peut être l’éviter.

NdT : Vous trouverez un tutoriel sur Carbon dans nos pages : Introduction à Carbon.

Avantages du développement en Carbon

Fonctionnalités bien documentées
Intégration avec les outils de développement de Mac OS X
Panel de fonctions très robustes
Intégration simple du C et du C++

Inconvénients du développement en Carbon

Pas de déploiement multi-plateforme

Technologies Graphiques de Bas Niveau

Avec peu de code il est facile de faire abstraction du code d’affichage du moteur de calcul sous-jacent, mais ce n’est souvent pas le cas. En particulier pour des applications faisant un intense usage des graphiques, vous souhaiterez peut-être tirer profit d’appels directs aux fonctionnalités fondamentales du système d’exploitation que vous ciblez. Vous aurez toujours besoin d’incorporer ces fonctionnalités dans une API de plus haut niveau pour l’afficher à l’écran et autoriser une interaction utilisateur, mais pour le jour où vous aurez besoin de manipuler les pixels de façons très spécifiques, Mac OS X vous offre un accès à trois technologies graphiques de première classe : Quartz, OpenGL et QuickTime.

Figure 4-3 Technologies Graphiques de Bas Niveau

Quartz

Quartz est le système graphique qui forme la fondation du modèle image de Mac OS X. Quartz vous apporte un modèle de dessin et un format d’affichage basés sur des standards. Quartz fournit à la fois un moteur de dessin à deux dimensions et l’environnement de fenêtrage de Mac OS X. Son moteur de dessin repose sur le modèle Portable Document Format (PDF) pour apporter des fonctionnalités de dessin d’une puissance professionnelle. Les services de fenêtrage fournissent des fonctionnalités de bas niveau telles que la gestion des fenêtres à mémoire tampon et la gestion des évènements tout comme la transparence. Quartz est couvert avec plus de détails dans Inside Mac OS X: System Overview et dans le site Web d’Apple qui lui est consacré (http://developer.apple.com/quartz/).

Avantages de Quartz

Fonctions de dessin comparables à celles de PostScript
Repose sur PDF
Outils de gestion des couleurs inclus
Modèles d’affichage et d’impression unifiés

Inconvénients de Quartz

Pas de déploiement multi-plateforme

OpenGL

OpenGL est une technologie standard de l’industrie pour les graphiques en 2D et en 3D. Il apporte des fonctionnalités de rendu, de mapping des textures, d’effets spéciaux et d’autres fonctions de visualisation. Il constitue une partie fondamentale de Mac OS X et il est implémenté sur de nombreuses plateformes. Etant donné son intégration dans de nombreux circuits électroniques et cartes vidéo, il revêt un intérêt particulier pour les programmes qui nécessitent des manipulations graphiques complexes. La page d’accueil d’OpenGL apporte plus d’informations sur cette technologie en général à http://www.opengl.org. La page d’Apple sur OpenGL, à http://developer.apple.com/opengl/, apporte plus d’informations sur la manière dont cette technologie est intégrée à Mac OS X.

Avantages d’OpenGL

Technologie multi-plateforme
Intégration native dans Mac OS X
Compris dans de nombreuses installations de Mac OS X
Ensemble de fonctions très robustes pour la gestion des graphiques

Inconvénients d’OpenGL

Quelques niveaux d’intégration au niveau application sont requis

QuickTime

QuickTime est une technologie multimédia pour la manipulation, l’enrichissement, le stockage et la fourniture de graphiques, de vidéos et de sons. C’est une technologie multi-plateforme qui fonctionne sur Mac OS aussi bien que sur Windows. Plus d’informations sur cette technologie sur http://developer.apple.com/quicktime/.

Avantages de QuickTime

Ensemble robuste de fonctions pour la manipulation du son et de la vidéo
Développement multi-plateforme

Inconvénients de QuickTime

Pas encore supportés sur les systèmes UNIX

Note : Bien que QuickTime en tant que tel ne soit pas supporté par les systèmes UNIX, le format de fichier QuickTime est supporté par de nombreux utilitaires de tierce partie.

Environnements Graphiques UNIX Traditionnels

Les systèmes d’exploitation UNIX ont grandi en incluant de nombreux environnements dans le but de fournir une interface graphique aux utilisateurs. Le Système X Window est probablement le plus connu. Au fur et à mesure que des besoins spécifiques sont apparus, d’autres architectures ont été développées sur la base d’une implémentation X11. Mac OS X n’utilise pas le Système X Window par défaut, mais des implémentations de X11 sont disponibles grace à des développeurs de tierce partie. Cela veut dire que des applications reposant sur le Système X Window peuvent être lancées, tout comme la plupart des environnements graphiques UNIX alternatifs. Cette section vous apporte plus de détails sur quelques uns de ces environnements.

X11R6

Mac OS X ne comprend pas d’implémentation par défaut de X11R6. Si vous avez l’intention de porter votre application sans ajouter de fonctionnalités Mac OS X, vous pouvez toujours lancer X11 sur Mac OS X. Avec votre application, vouos devriez alors distribuer une implémentation de X11 ou au moins donner les instructions aux utilisateurs pour en télécharger et configurer une. Il existe des implémentations commerciales et gratuites de X11 sur Mac OS X.

XTools par Tenon Intersystems (http://www.tenon.com) et eXodus de Powerlan USA fournissent tous les deux des serveurs X11 qui coexistent avec Aqua. Si vous n’avez pas besoin d’une implémentation commerciale du Système X11, XFree86 offre gratuite une implémentation gratuite de X86. La version Mac OS X de XFree86 est un projet actif doté d’un support intégrale de la part du projet XDarwin. Plus d’informations sur le projet XDarwin y compris des astuces d’installation de X11 sont disponibles sur http://www.xdarwin.org. XFree86 en tant que tel peut être téléchargé sur http://xfree86.org/.

Avec une implémentation d’un Système X Window, vous êtes maintenant libre d’utiliser les toolkits auxquels vous êtes habitués tels que GTK ou KDE.

Avantages du Développement X11R6

Le standard de-facto en matière de technologie d’affichage sur les systèmes UNIX
Implémentation open source disponible
Quelque peu portable sur certains systèmes embarqués

Inconvénients du Développement X11R

Environnement de développement compliqué
Nécessite un large panel de composants installés
N’est pas natif sur Mac OS X

Tcl/Tk

Il y a une version native de Tk disponible sur http://tcl.sourceforge.net. Avec ceci vous pouvez aisément ajouter des éléments graphiques à vos scripts Perl, Python ou Tcl.

Avantages du Développement Tk

Environnement de développement multi-plateforme
Intégration aisée avec les scripts Tcl et Perl
Implémentation open source disponible

Inconvénients du Développement Tk

Pas encore supporté par défaut dans Mac OS X

Qt

Qt est un ensemble d’outils C++ pour la construction d’interfaces utilisateur graphiques. Il est très populaire dans le monde UNIX compte tenu du fait qu’il est utilisé par le très populaire “K Desktop Environment”, KDE. Trolltech détient une version native de Qt, Qt/Mac, disponible pour Mac OS X. Si vous avez déjà une application C++ ou si vous êtes sur le point d’en construire une, Qt vous permet de construire des applications qui tourneront nativement sur Mac OS, tout autan que sur GNU/Linux et Windows. Plus de détails sur Qt/Mac sont disponibles sur http://www.trolltech.com. Qt/Mac ne tourne pas au-dessus de X11 sous Mac OS X, mais le code source est compatible avec l’implémentation X11 de Qt.

Avantages du Développement Qt

Environnement de développement multi-plateforme
Intégration aisée avec les codes source C++
Ensemble robuste de fonctions

Inconvénients du Développement Qt

Peut nécessiter la license de logiciels de tierce-partie

Fonctions Supplémentaires

Bien que pas mal de parties de Mac OS X soient semblables à celles d’autres systèmes UNIX, Mac OS X comprend aussi beaucoup de choses qui le rendent différent. Cette section met en exergue quelques uns des espaces clés auxquels vous devriez être sensibilisés. Cela n’aura que peu d’importance pour le portage basique d’une application simple, mais plus votre application sera robuste et plus elle s’intégrera étroitement aux couches sous-jacentes du système, plus il est important de comprendre les fonctionnalités supplémentaires fournies par le système d’exploitation. Cette section fait l’inventaire des détails clés qui distinguent Mac OS X des autres systèmes UNIX. La plupart des informations prodiguées ici le sont sous forme d’aperçu avec des références aux endroits où l’information est couverte plus en détail.

Architecture Audio

Avec Mac OS X, Apple a mis à disposition la plupart des fonctionnalités audio qui sont normalement associées à la technologie MIDI de tierce-partie et d’autres protocoles audio directement dans le système d’exploitation. Cela donne aux développeurs une plateforme simple pour développer des applications audio dynamiques. Pour les utilisateurs finaux, cela minimise la configuration qui est normalement requise pour faire en sorte que des applications audio sophistiquées fonctionnent. En tant que développeur UNIX, cela veut dire que vous avez cherché une plateforme pour y développer des applications audio robustes, ne cherchez plus. Parmi les fonctions de haut niveau du sous-système Code Audio de Mac OS X, nous avons :

audio multi-canal natif avec support des plug-ins
MIDI natif
Hardware Abstraction Layer (HAL) audio (Couche d’Abstraction Matériel)
un pilote de classes USB intégré compatible avec les spécifications audio USB
un modèle simplifié de pilote
une relation directe avec le Kit I/O au travers de la classe IOAudioDevice qui autorise le développement rapide de pilote de périphérique

Si vous développez des applications qui nécessitent un accès à la couche audio de Mac OS X, vous pouvez rechercher les ressources d’extension disponibles sur http://developer.apple.com/audio/.

Séquence de Démarrage

Un examen de /etc/rc révelle les Start System Services, d’où le System Starter est appelé. C’est un point d’entrée inhabituel sur la plupart des systèmes de style UNIX. Le System Starter est une application qui offre beaucoup d’avantages aux développeurs qui ont besoin de lancer quelque chose au démarrage. Il démarre de nombreux services disponibles sous Mac OS X qui en général sont lancés à partir de /etc/rc. Sous Mac OS X, /etc/rc comporte les éléments de base du démarrage puis le System Starter prend le relais pour les fonctionnalités supplémentaires. Cela permet à plusieurs services de démarrer en tandem, cela apporte une méthode plus robuste pour vérifier les dépendances entre services plutôt que seulement le temps de démarrage, et cela permet même à des chaînes de caractères localisées d’être affichées à l’écran au moment du démarrage. Dès qu’il est invoqué, le System Starter regarde d’abord le contenu de /System/Library/StartupItems puis de /Library/StartupItems pour trouver les services à lancer. Dans chacun de ces répertoires vous pouvez voir des exemples de services qui sont lancés par Mac OS X.

Chaque services à lancer consiste en un répertoire avec au moins deux éléments :

Un script shell qui contient le même type de commande que l’on trouve traditionnellement dans /etc/rc. Le moment où ce script est lancé dans la procédure de démarrage est déterminé par le StartupParameters.plist. Ce fichier a le même nom que le répertoire qui l’abrite.
StartupParameters.plist est un fichier XML comportant un simple DTD clé-valeur. La liste de propriété détermine quels services seront lancés à quel moment, en prenant en compte les dépendances entre services. Il fournit aussi des descriptions sur les services et des chaînes de caractère à afficher sur l’interface utilisateur au moment du démarrage du système.

En option, il contient un répertoire de Ressources dans lequel vous pouvez introduire des chaînes de caractères localisées pour les messages affichés à l’écran.

En guise d’exemple sur la manière dont tout ça fonctionne, jetez un oeil au contenu à l’un des services inclus : Apache. Dans /System/Library/StartupItems/Apache, vous voyez Apache, Resources et StartupParamaters.plist.

Apache, sous Mac OS X 10.2, contient un script shell dont l’action est très directe pour le démarrage et l’arrêt :

#!/bin/sh
##
# Apache HTTP Server
##
. /etc/rc.common
StartService ()
{
    if [ "${WEBSERVER:=-NO-}" = "-YES-" ]; then
        ConsoleMessage "Starting Apache web server"
        apachectl start
    fi
}
StopService ()
{
    ConsoleMessage "Stopping Apache web server"
    apachectl stop
}
RestartService ()
{
    if [ "${WEBSERVER:=-NO-}" = "-YES-" ]; then
        ConsoleMessage "Restarting Apache web server"
        apachectl restart
    else
        StopService
    fi
}
RunService "$1"

StartupParamaters.plist, tel qu’illustré Listing 5-1, est un peu plus structuré. C’est un listing compact de propriétés qui identifient l’élément particulier qui est démarré ainsi que les services qu’il fournit et quels sont les prérequis pour le lancer.

Listing 5-1 : Un fichier de démarrage d’éléments StartupParamaters.plist.

{
  Description     = "Apache web server";
  Provides        = ("Web Server");
  Requires        = ("DirectoryServices");
  Uses            = (“Disks”, "NFS", "Network Time");
  OrderPreference = "None";
}

Les ressources du répertoire contiennent des chaînes de caractères localisées qui sont envoyées à l’écran. Mac OS X détermine quel langage utiliser en se basant sur le langage par défaut paramétré dans les Préférences Système. Il cherche ensuite le fichier Localizable.strings dans le dossier correspondant à ce langage afin d’y trouver les éventuelles chaînes de caractères qui prendraient le dessus sur celles placées dans StartupParameters.plist. Si tel est le cas, il affiche la chaîne de caractères appropriées à la place de celle affichable par défaut.

Fichier de Configuration

Souvent sur un système UNIX vous trouvez des fichiers de configuration dans /etc. Cela est toujours vrai sur Mac OS X, mais des informations de configuration sont aussi présentes dans d’autres lieux. Le Réseau, les Impressions et les détails de la configuration système d’un utilisateur sont régulés par défaut par la base de données NetInfo. Les applications font en général usage des listes de propriétés XML (plists) pour gérer les informations de configuration. Vous pouvez voir beaucoup d’exemples de listes de propriétés en regardant dans ~/Library/Preferences.

Il est important de garder à l’esprit que si le fait de changer un fichier de configuration dans /etc ne provoque pas l’effet escompté, vous devriez aussi regarder si cette information n’est pas gérée dans la base de données NetInfo ou si elle est couverte dans la liste de propriétés d’une application.

Pilotes de Périphériques

Mac OS X implémente un modèle de programmation orienté objet pour développer des pilotes de périphériques. Cette technologie est appelée le Kit I/O. C’est un ensemble de frameworks système, de librairies, d’outils et d’autres ressources. Ce modèle est différente de celui trouvé traditionnellement sur les systèmes BSD. Si votre code nécessite un accès à un périphérique autre qu’un disque dur, vous utiliserez le Kit I/O. La programmation du Kit I/O se fait grace à un sous-ensemble restreint de C++ qui fait l’impasse sur des fonctions dont l’usage est inaproprié dans un noyau multi-traitement. En modélisant le matériel connecté à un système Mac OS X et en extrayant les fonctionnalités communes des périphériques appartenant à des catégories particulières, le Kit I/O perfectionne la phase de développement de pilotes. Plus d’informations et de docmentations sur le Kit I/O sont disponibles sur http://developer.apple.com/techpubs/macosx/Darwin/IOKit/iokit.html.

Le Système de fichiers

Le système de fichiers de Mac OS X est similaire à celui des autres systèmes UNIX, mais il y a quelques différences notables qui sont décrites ci-dessous.

Structure du Système de Fichiers

Basiquement, la structure du système de fichiers de Mac OS X est similaire à celle d’un système BSD. Un coup d’oeil rapide sur hier(7) devrait vous rassurer. Lorsque vous avez un doute sur l’endroit où mettre des choses, vous pouvez les mettre là où vous le feriez sous des systèmes BSD. Il y a quelques répertoires différents que vous devriez recoonaître.

Le comportement par défaut du Finder de Mac OS X consiste à masquer les répertoires qui normalement ne revêtent aucun intérêt pour les utilisateurs, tout comme les fichiers invisibles et ceux dont le nom commence par un “.”. Cette apparence est maintenue par le Finder pour promouvoir la simplicité de l’interface. En tant que développeur, vous souhaiterez voir les fichiers “.” et l’organisation complète des répertoires. /usr/bin/defaults vous permet de surpasser le masquage par défaut des fichiers invisibles. Pour afficher tous les fichiers que le Finder masque normalement, tapez les commandes suivantes dans le shell :

defaults write com.apple.Finder AppleShowAllFiles true

Puis redémarrez le Finder soit en vous reconnectant soit en choisissant Forcer à quitter dans le menu Pomme.

Il y a d’autres manières simples de voir le contenu des dossiers masqués sans modifier le comportement par défaut du Finder. Vous pouvez utiliser la commande /usr/bin/open ou la commande “Aller au dossier” du Finder. Avec open(1) vous pouvez ouvrir un répertoire sous le Finder, masqué ou pas, à partir du shell. Par exemple, open /usr/include ouvre le dossier masqué dans une nouvelle fenêtre du Finder. Si vous êtes dans le Finder et souhaitez voir le contenu d’une hiéarachie de dossiers masquée, sélectionnez “Aller au dossier” dans le menu Aller, ou pressez juste Command-~, et tapez le chemin d’accès da la destination souhaitée.

Pour plus d’informations sur la manière d’organiser la structure de répertoires de vos applications Mac OS X, consultez Inside Mac OS X : Aqua Human Interface Guidelines et Inside Mac OS X: System Overview.

Types de Systèmes de fichiers Supportés

Mac OS X supporte Mac OS Extended (HFS+), le format traditionnel des volumes Macintosh, et l’UNIX File System (UFS). HFS+ est recommendé et représente ce que la plupart des utilisateurs ont sur leur système. Quelques installations de type serveur ont leur système sur UFS. Si vous développez sur UFS, vous devrez aussi tester complètement votre code sur un système HFS+. La chose importante à retenir des systèmes de fichiers HFS+ est que bien qu’il préserve la casse, il n’est pas sensible à la casse. Cela veut dire que si vous avez deux fichiers dont la différence de nom ne tient que dans la casse, le système HFS+ les considérera comme identiques. C’est rarement un problème, mais c’est quelque chose auquel vous devrez faire attention. Lors de la conception de votre application, vous prendrez soin de ne pas placer deux objets dont le nom ne diffère que pas la casse dans le même répertoire—par exemple, Makefile et makefile.

Cependant, le fait de développer sur HFS+ n’assuera pas nécessairement la compatibilité de votre application sur UFS. Il est très facile d’écrire du code faisant que votre programme ouvre le fichier org.mklinux.formattool.prefs une première fois et le fichier org.MkLinux.formattool.prefs une autre fois et obtienne des résultats complètement différents.

Aussi, ne supposez pas qu’un bug n’a pas d’importance simplement parce que vous l’avez constaté sur UFS. D’autres systèmes de fichiers ont des propriétés similaires, comprenant potientiellement un partage NFS, SMB ou AFP, particulièrement quand ces partages sont servis par autre chose qu’un Mac. Ainsi, un bug apparaissant sur un système de fichiers apparaîtra sur d’autres.

Le Noyau

Le coeur de tout système d’exploitation consiste en un noyau. Le noyau de Mac OS X est aussi connu en tant que XNU. Bien que Mac OS X partage la plupart de son architecture sous-jacente avec BSD, le noyau est une zone où ils diffèrent de manière significative. XNU est basé sur une conception de micro-noyau Mach, mais il comprend aussi des fonctions BSD. Ce n’est pas techniquement parlant une implémentation de micro-noyau, mais il bénéficie quand même de la structure d’un micro-noyau.

Pourquoi est-ce conçu ainsi ? Un Mach pure vous permet de lancer un système d’exploitation dans un process séparé ce qui permet plus de flexibilité, mais peut aussi ralentir les choses du fait des traductions effectuées entre le Mach et la couche supérieure. Avec Mac OS X, puisque le comportement désiré du système d’exploitation est connu, des fonctionnalités BSD ont été incorporées dans le noyau aux côtés de Mach. Le résultat fait que le noyau combine la puissance de Mach avec celle de BSD.

Quel rapport avec les taches que le noyau doit accomplir ? Figure 5-1 illustre comment les différentes personnalités du noyau se manisfestent.

Figure 5-1 Personnalités XNU

Les aspects Mach du noyau prennent en charge :

la gestion de la mémoire
la messagerie Mach et la communication inter-process (IPC) Mach
les pilotes de périphériques

Les composants BSD

gèrent les utilisateurs et les autorisations
contiennent la pile réseau
fournissent un système de fichiers virtuel
maintiennent la couche de compatibilité POSIX.

Reportez-vous à Mac OS X: Kernel Programming pour plus d’informations sur les raisons pour lequelles vous souhaiteriez (ou ne souhaiteriez pas) programmer pour le noyau, y compris des propos sur le mécanisme d’extension du noyau (KEXT).

NetInfo

NetInfo est le système intégré de gestion des répertoires de Mac OS X que le système et les processus applicatifs peuvent utiliser popur stocker et trouver des informations administratives sur les ressources et les utilisateurs. NetInfo fait référence à la base de données qui stocke ces informations tout comme il fait référence aux processus par lesquels ces informations sont prodiguées au système. Par défaut, chaque ordinateur Mac OS X exécute à la fois les processus client et serveur, ce dernier ne servant que le client local. Vous pouvez aussi relier des ordinateurs client à des serveurs autres que le serveur local. Les informations sont alors accédées selon un schéma hierarchique dans lequel chaque ordinateur client accède à l’union des informations fournies en premier par son serveur NetInfo local et de celles des serveurs de plus haut niveau auxquels il est relié.

Il est important de se soucier de NetInfo parce qu’il représente par défaut la manière selon laquelle Mac OS X stocke les informations relatives aux utilisateurs et à certains aspects réseau. Quand un utilisateur est ajouté, le système ajoute automatiquement ses informations à la base de données NetInfo. Des outils traditionnels tels que adduser ne fonctionne pas tel que vous pourriez l’espérer. Vous pouvez ajouter des utilisateurs de plusieurs manières :

au travers du panneau Utilisateurs des Préférences Système
au travers de /Applications/Utilities/NetInfo Manager
à partir de la ligne de commande (voir “Exemple : Ajout d’un Utilisateur à partir de la Ligne de Commande”)

Plus de détails peuvent être trouvés sur NetInfo dans netinfo(5) et lookupd(8). Understanding and Using NetInfo apporte un bon aperçu. netinfo(3), netinfo(5), nidump(8), nicl(8), nifind(1), niload(8), niutil(1) et nireport(1) tournent autour des détails d’implémentation.

Exemple : Ajout d’un Utilisateur à partir de la Ligne de Commande

Cette section montre un exemple simple d’utilisation de l’outil NetInfo à ligne de commande niutil pour ajouter un utilisateur au système. L’exemple spécifie quelques unes des propriétés que devriez normalement affecter à tout utilisateur.

Créer une nouvelle entrée dans le domaine local (/) sous la catégorie /users.niutil -create / /users/username
Créer et régler la propriété shell sur bash.niutil -createprop / /users/username shell /bin/bash
Créer et affecter le nom complet de l’utilisateur.niutil -createprop / /users/username realname "User Name"
Créer et affecter l’ID de l’utilisateur.niutil -createprop / /users/username uid 503
Créer et affecter la propriété ID global de l’utilisateur.niutil -createprop / /users/username gid 1000
Créer et affecter le nom d’utilisateur au domaine local en opposition au domaine réseau ou tout autre domaine.niutil -createprop / /users/username home /Local/Users/username
Créer une entrée pour le mot de passe.niutil -createprop / /users/username _shadow_passwd
Affecter maintenant le mot de passe.passwd username
Pour rendre cet utilisateur utile, vous souhaiterez peut être l’ajouter au groupe des administrateurs.niutil -appendprop / /groups/admin users username

C’est essentiellement ce que les Préférences Système effectuent lorsque vous créez un nouvel utilisateur, cette présentation a pour but de vous montrer ce qui se passe derrière le rideau avec la base de données NetInfo. Un coup d’oeil sur les hiérarchies dans l’application Gestionnaire NetInfo vous aidera aussi à comprendre comment la base de données est organisée.

Authentification basée sur le rôle

Par défaut il n’y a pas d’utilisateur root dans Mac OS X. C’est un choix de conception délibréré à la fois pour des notions de sécurité et pour simplifier l’interface utilisateur. Vos applications ne doivent pas supposer qu’un utilisateur ait besoin d’un accès au système en tant que super-utilisateur. Pour les utilisateurs expérimentés et les développeurs, sudo est fournie pour lancer des applications nécessitant des autorisations dans le shell. Ces applications peuvent aussi être lancées par le membres du groupe admin. Par défaut, le groupe admin est compris dans la liste des “sudoers“. Vous pouvez affecter des utilisateurs au groupe admin via les Préférences Système :

Cliquez sur le bouton Comptes.
Sélectionnez un utilisateur à partir de la liste et cliquez sur Modifier Utilisateur, ou créez un nouvel utilisateur.
Cochez “Autorisation à administrer cet ordinateur”.
Cet utilisateur peut maintenant utiliser des applications administratives tout autant que la commande sudo dans le shell.

Bien qu’il soit généralement considéré comme dangereux de se connecter sous l’utilisateur root, cela est mentionné ici puisque l’utilisateur root est souvent utilisé pour installer des applications ou dans certains scénarii de développement. Si vous devez activer vous même root lors d’un développement :

Lancez /Applications/Utilitaires/Gestionnaire NetInfo.
Sélectionnez Domain > Security > Authenticate.
Entrez votre nom d’administrateur et votre mot de passe lorsqu’ils vous sont demandés.
Sélectionnez maintenant Domain > Security > Enable Root User. La première fois que vous ferez cela, vous devrez assigner un mot de passe à root.

Autrement, vous pouvez utiliser sudo passwd root à partir du shell et appliquer le mot de passe de manière appropriée à root.

Important

Ne supposez pas qu’un utilisateur final puisse activer l’utilisateur root. Cette information est prodiguée pour vous aider dans vos travaux de développement uniquement.

Langages de Scripting

Mac OS X détient la faculté de lancer des scripts shell dans son shell natif compatible sh, zsh ou dans le csh et le tcsh, compris tous les deux. vous pouvez aussi lancer Ruby, Perl, Python ou d’autres scripts que vous avez développés. En plus, Mac OS X fournit un langage de script spécifique Apple, AppleScript. Bien que AppleScript soit immensément puissant et puisse être utilisé pour construire des applications par lui-même, il est important de noter qu’il est principalement conçu pour communiquer avec des composants graphiques du système d’exploitation. Il y a d’autres utilisations que vous pouvez lui trouver, mais il ne remplace pas les langages de script UNIX. Vous pouvez vous en servir, cependant, pour placer un front-end sur vos scripts traditionnels.

AppleScript est conforme au langage Open Scripting Architecture (OSA), et peut être utilisé à partir de la ligne de commande via la commande osascript(1). D’autres langages peuvent être rendus compatibles OSA autorisant ainsi l’interactivité avec le système d’exploitation.

Services de Sécurité

Mac OS X implémente la Common Data Security Architecture (CDSA - Architecture de la Sécurité des Données Ordinaires). Si vous devez utiliser les Authorization Services, le Secure Transport ou des certificats dans le périmètre de CDSA, une documentation est disponible en ligne à http://developer.apple.com/techpubs/macosx/CoreTechnologies/ dans la section Security Services.

En plus, Mac OS X fournit OpenSSL et PAM pour faciliter le portage des applications UNIX vers Mac OS X.

Distribuer votre Application

Le développement d’une application n’est qu’une partie de toute l’histoire. Vous devez maintenant lui faire voir le jour pour que les utilisateurs s’en servent. Etant donné que c’est un système d’exploitation UNIX, vous pourriez juste compresser votre fichier en tar puis en gzip, mais cela risque de refroidir l’utilisateur lambda. Pour rendre votre transition complète, vous devrez packager votre application de la même sorte que les autres applications Mac OS X. Ce chapitre vous guide au travers de certains de ces détails puisqu’il y a des chances qu’ils soient nouveaux pour vous, développeur UNIX.

Packager la

La forme recommandée de distribution d’une application est une image disque compressée. Cela permet la préservation des resource forks qui pourraient être présents, une installation par simple glisser-déposer, ainsi que le cryptage de données si nécessaire. Si votre application est un simple bundle applicatif, vous pouvez tout simplement placer votre bundle aux côtés des documentations pertinentes sur une image disque grace à Images Disque, la compresser et la distribuer. Si vous avez une application qui nécessite des privilèges d’administrateur pour son installation dans des répertoires à accès restreint ou qui nécessite plus qu’une simple installation par glisser-déposer, vous devrez utiliser /Developer/Applications/PackageMaker pour construire des packages d’installation qui seront traités par l’application Installer d’Apple. Les bases de l’utilisation de Images Disque pour constituer une image disque sont données dans le paragraphe sui suit. Pour obtenir de l’aide sur l’utilisation de PackageMaker, sélectionnez PackageMaker Help dans le menu Help de PackageMaker.

Images Disque

Les étapes suivantes vous montrent comment packager votre application sous forme d’image disque (fichier dmg) pour une distribution sur Mac OS X.

Ouvrez /Applications/Utilitaires/Images Disque en double-cliquant dessus.
A partir du menu Fichier, sélectionnez Nouveau -> Image vide. Images Disque ouvre alors une fenêtre contenant des options de personnalisation telles qu’illustrées Figure 6-1.
Dans le champ “Enreg. sous :”, saisissez le nom du fichier compressé que vous allez distribué. Par défaut, un suffixe .dmg est ajouté au nom que vous saisissez. Bien qu’il ne soit pas requis, c’est une bonne idée que de garder ce suffixe pour plus de clarté et de simplicité.
Dans le champ “Nom du Volume”, saisissez le nom du volume que vous voulez voir apparaître sur le Bureau de l’ordinateur de l’utilisateur. Habituellement, on y place le même nom que celui saisi pour le fichier compressé mais sans le suffixe.dmg.
Dans la partie explorateur de fichier, choisissez l’emplacement de sauvegadre de votre fichier. Cela n’a rien à voir avec l’endroit où sera installé le fichier sur l’ordinateur de l’utilisateur final, ce n’est que l’endroit où sauvegarder le fichier sur votre ordinateur.
Réglez la “Taille”, à partir du menu déroulant, suffisamment grande pour contenir votre application.
Habituellement vous laissezrez le Format à Mac OS Extended (le format de fichier HFS+).
Laissez “Cryptage” sur “Vide”. Si vous changez cette option, l’utilisateur final devra saisir un mot de passe avant de pouvoir monter l’image disque, ce qui n’est pas un manière normale de distribution d’une application.
Cliquez sur Créer.

Figure 6-1 Options Images Disque

Une fois que vous avez une image disque, montez là en double-cliquant dessus. Vous pouvez maintenant copier vos fichiers vers cette image montée. Une fois que tous les fichiers requis sont en place, vous devrez basculer votre image en “lecture seule”. De nouveau dans Images Disque :

Sélectionnez Fichier -> Convertir l’image.
Dans le navigateur de fichiers, sélectionnez l’image disque que vous venez de modifier et cliquez sur Convertir.
Sélectionnez un emplacement pour sauvegarder le fichier qui en résultera, changer le format de l’image en “Lecture seule” et cliquez sur Convertir.

Vous avez maintenant une image disque pour votre application qui est facilement distribuable.

Faites la connaître du monde entier

Une fois que vous avez une application, comment diffuser cette information ? D’abord, faites en sorte qu’Apple le sache. Pour que votre application soit listée sur la page de téléchargement principale Mac OS X d’Apple, allez à http://www.apple.com/downloads/macosx/submit/ et renseignez les informations appropriées pour votre application. Vous devriez aussi aller sur http://guide.apple.com/ et, en bas de la page, cliquer sur Submit a Product pour que votre application soit listée dans le Guide Apple. Vous devriez aussi aller sur http://www.versiontracker.com/ et sur les de news Macintosh tels que http://www.maccentral.com/ et http://www.macnn.com/ (NdT : pour une visibilité internationnale. Et sur http://www.macgeneration.com/ et http://www.macplus.org/, pour une visibilité francophone.).

Glossaire

ADC: Voir Apple Developer Connection

Apple Developer Connection: La source principale des ressources techniques et business, et des informations pour quiconque développant pour les plateformes logiciels et matériels d’Apple dans le mmonde. Elle comprend des programmes, des produits et des services, et un site Web comprenant des documentations techniques à jour relatives aux technologies émegeantes et existantes d’Apple. L’Apple Developer Connection est à l’adresse http://www.apple.com/developer/.

Aqua: L’interface graphique utilisateur de Mac OS X.

bom (Bill Of Materials): Un fichier contenu dans un package d’installation utilisé par l’Installateur pour déterminer quels sont les fichiers à installer, à retirer ou à mettre à jour. Il contient tous les fichiers à l’intérieur d’un répertoire, aux côtés d’informations relatives à chaque fichier telles que les autorisations du fichier, son propriétaire et son groupe, sa taille, le moment de sa dernière modification, un somme de contrôle pour chaque fichier et des informations relatives aux liens en dur.

bundle: Un répertoire du système de fichiers qui stocke le code exécutable et les ressources logiciel en rapport avec ce code. Les applications, les plug-ins et les frameworks sont des types de bundle. Mis à part les frameworks, les bundles sont des packages de fichiers, presentés par le Finder sous la forme d’un seul fichier.

Carbon: Un environnement applicatif pour Mac OS X qui présente un ensemble d’interfaces de programmation dérivées des versions antèrieures de Mac OS. L’API Carbon a été modifiée pour fonctionner correctement avec Mac OS X, en particulier avec les fondations du système d’exploitation, l’environnement noyau. Les applications Carbon peuvent tourner sous Mac OS X, Mac OS 9 et toute version de Mac OS 8 supérieures à Mac OS 8.1.

Classic: Un environnement applicatif pour Mac OS X qui vous permet de lancer des logiciels Mac OS non carbonnisés. Il supporte les programmes construis à la fois pour les architectures de puce Power PC et les 68K et est complètement intégré au Finder et aux autres environnements applicatifs.

Cocoa: Une plateforme de développement avancé orienté objet pour Mac OS X. Cocoa est un ensemble de frameworks et d’interfaces de programmation à la fois en Java et en Objective-C. Il est basé sur l’intégration d’OPENSTEP, des technologies Apple et de Java.
Darwin: Un autre nom pour le coeur du système d’exploitation Mac OS X. Le noyau Darwin est équivallent au noyau Mac OS X complété des librairies BSD et de l’environnement ligne de commande de BSD. Darwin est une technologie open source.

Darwin committer: Un individu auquel a été confié des droits d’écriture dans l’arbre CVS du coeur du système d’exploitation d’Apple. Pour savoir comment devenir un Darwin committer rendez-vous sur http://www.opensource.apple.com/.

dmg: Un fichier image disque Mac OS X.

Finder: L’application système qui agit en tant qu’interface principale avec le système de fichiers.

HFS (Hierarchical File System): Le format de fichiers standard de Mac OS, utilisé pour représenter un ensemble de fichiers sous forme de hiérarchie de répertoires (dossiers), chacun d’entre eux pouvant contenir soit des fichiers soit des dossiers. HFS est un format de volume à deux forks.

HFS+: Le format de fichiers étendu de Mac OS. Ce format de système de fichiers a été introduit avec Mac OS 8.1, permettant le support des noms de fichiers de plus de 31 caractères, une représentation Unicode des fichiers et des noms de répertoire, et des opérations efficaces sur des disques très grands. HFS+ est un format de volume à forks multiples.

Mach-O: Le format exécutables des fichiers objet Mach. C’est le format par défaut des exécutables sous Mac OS X.

NetInfo: La base de données des informations administratives réseau de Mac OS X et le système d’interrogation de ces informations. Beaucoup de services de Mac OS X consultent la base de données NetInfo pour y trouver des informations de configuration.

fichier nib: Une archive XML qui décrit l’interface utilisateur des applications construites avec Interface Builder.

Fichier .pkg: Un fichier Installateur Mac OS X. Ils peuvent être regroupés au sein d’un méta-package (.mpkg).

Plist: Voir Property List.

Project Builder: Environnement de développement intégré et graphique d’Apple. Il est gratuit et disponible avec le package des Outils de Développement Mac OS X.

Property List: Une représentation structurée et textuelle de données qui utilise le Extensible Markup Language (XML) comme média structurant. Les éléments d’une liste de propriétés représentent des données d’un certain type, tels que les tableaux, les dictionnaires et les châines de caractère.

XNU: Le noyau de Mac OS X. L’acronyme récursif signifie X’s Not Unix. Il combine des fonctionnalités de Mach et de BSD tout comme le support sous-jacent du Kit I/O, le modèle des pilotes de Mac OS X.