En route vers MacOS X : les fichiers
Avec MacOS X, son nouveau système d’exploitation basé sur un noyau Unix, Apple fait le pari qu’il sera capable d’offrir le nec plus ultra en la matière. Retour cette semaine sur l’épopée du nouveau système Mac. Aujourd’hui, le casse-tête des fichiers.
TROISIEME PARTIE. Les systèmes de fichiers utilisés dans MacOS sont les systèmes HFS+ et HFS. Lorsque vous formatez votre disque dur, c’est l’un ou l’autre système qui est installé. Des deux, HFS+, plus récent et plus évolué est également plus compatible avec Unix, la pierre de base du nouvel OS d’Apple. Outre le fait qu’il permet de sauvegarder les données dans un espace minimal de 4 Ko (au lieu de 26 avec HFS), il peut utiliser des données de données, des meta-données, dont Unix raffole. Problème : il est conçu pour les fichiers Mac, qui sont bicéphales. Ils contiennent en effet deux parties : les ressources d’une part, les données proprement dites d’autre part. Ces dernières contiennent les véritables informations de l’utilisateur, c’est-à-dire, les textes, les nombres, les images? L’autre rassemble des éléments comme des boîtes de dialogues spécifiques, des icônes, des menus ou des codes de programmes. Habituellement, les applications ne disposent que de la partie ressources, alors que les fichiers jouent des deux parties.
Sous Unix et par extension sous MacOS X ainsi que pour les applications « Carbonisées », la partie des ressources est séparée de la partie des données pour devenir un fichier à part entière. Ce problème est bien connu des utilisateurs qui effectuent des transferts de fichiers via Internet s’ils n’utilisent pas une technique d’encodage comme Mac Binary, AppleDouble, Mime ou autre Base64. Un logiciel envoyé par e-mail ne peut pas fonctionner sur l’ordinateur de destination car la partie ressources a été « oubliée ». L’encodage permet de mêler la partie ressources à la partie données, dans un fichier unique. Dans ces conditions, un fichier peut être envoyé sans problème. Sur MacOS X, les deux têtes d’un même fichier deviennent deux fichiers distincts liés entre eux, le tout de manière transparente pour l’utilisateur.
Le passage à Unix ne sera toutefois pas évident. Les ingénieurs d’Apple ont dû faire avancer sérieusement la compatibilité. Sans vouloir entrer trop dans les détails, il est important de savoir que « chemins d’accès » aux fichiers, le plus souvent invisibles aux yeux des utilisateurs dans un environnement graphique, s’appuient sur des syntaxes différentes selon le système utilisé. Ainsi, sur MacOS, on trouvera « disque dur:applications:IBM ViaVoice », qui permet au système de retrouver le logiciel de dictée vocale installé sur le disque dur de la machine. Sous Unix, le chemin d’accès ressemble à celui de MacOS, avec deux différences : Unix n’autorise pas les espaces, et le séparateur n’est pas le deux points « : », mais la barre oblique « / ». On aura donc : « disque_dur/applications/IBM_ViaVoice ».
Différence de taille, car si le disque dur autorise l’inscription du « : », le noyau de MacOS X, basé sur Unix, attend un « / », une traduction est donc réalisée. Quant aux applications fonctionnant sur l’actuel MacOS, elles attendent aussi « : ». De sorte que le module Carbon est obligé de faire une nouvelle traduction du chemin d’accès.
Cet exemple n’est qu’un aperçu des problèmes rencontrés par les ingénieurs d’Apple dans leur course à la transition du système. Mais il permet de comprendre combien la modification de fond du système, si elle augmente les performances des Macintosh, sera quasiment invisible ou transparente pour les utilisateurs qui pourront continuer à utiliser des fichiers de l’un à l’autre système sur des disques durs formatés sous MacOS ou au format UFS d’Unix sans s’apercevoir de la mécanique en oeuvre.
Demain : une nouvelle fonctionnalité?les applications localisées automatiques.
Pour en savoir plus :