1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

64 bits




Tiger incluait le support des processus 64 bits, mais seulement s'il n'utilisait pas l'une des API graphiques principales du système. Voilà comment le futur en 64 bits de Mac OS X m'était apparu à l'époque :

Il y a peu de bénéfices à être un processus 64 bits pour la plus grande majorité des applications graphiques (GUI). Néammoins, il est prudent de considérer que en fin de compte, tous les Macs vont avoir des CPUs 64 bits. L'introduction de versions 64 bits sur tous les sous-systèmes de Mac OS X (Carbon, Cocoa, Core Foundation, Quick Time, Quartz, etc...) semble inévitable.

Je me demande seulement quel bénéfice il y aura à introduire ces éléments l'un après l'autre[...] De toute façon, toutes les bibliothèques graphiques de haut niveau reposent sur des services de bas niveau comme Quartz et Core Foundation. Si bien qu'il me semble que la meilleure transition dans le futur, sera de délivrer un système 64 bits complet en une seule fois. C'est une demande exigeante, et c'est pourquoi je pense que cela prendra du temps.

Eh bien, il s'est à coup sûr passé du temps depuis Tiger, et devinez quoi ? Léopard est une version qui est en 64 bits d'un coup, sous certaines conditions... mais avant d'y arriver, je veux revenir sur l'idée selon laquelle "Il y a peu de bénéfices à être un processus 64 bits pour la plus grande majorité des applications graphiques".

J'avais écris cela avant la transition d'Apple vers les processeurs Intel. Du fait de l'histoire tortueuse du jeu d'instructions x86, il y a effectivement des améliorations de performances pour la plupart des applications quand on passe du 32 bits Intel (x86) au 64 bits Intel (x86_64). Le tableau ci-dessous explique pourquoi. 32/64 CPUs

Le jeu d'instructions du Power PC fut conçu avec une implantation 64 bits à l'esprit ; sa "transition" à 64 bits n'avait en fait pas lieu d'être. D'un autre côté, le jeu d'instructions x86 fut créé pendant l'ère 16 bits, et a accumulé une bonne quantité de scories (cruft) en passant du 16 au 32 bits. Certaines de ces scories ont été sagement abandonnées pendant la transition de 32 vers 64 bits. Les applications compilées pour x86_64 ne disposent pas seulement de registres plus grands, elles ont aussi plus de registres, et des conventions d'appel plus modernes, et plus de modes d'adressage.

Toute application x86 32 bits peut profiter de ces changements, la question est seulement de savoir quel va être l'intérêt de ces bénéfices. Ce n'est pas vrai des applications Power PC, qui utilisent de la mémoire en plus, et subissent la pression des registres de 64 bits sur le cache, sans aucun des bénéfices associés à l'abandon des scories d'Intel.

Je parle "d'Applications x86" et "d'applications Power PC", mais bien sûr, Léopard, comme Tiger, supportent ce qu'Apple appelle des Binaires universels. Ce sont des fichiers uniques exécutables, qui contiennent du code pour toutes les architectures supportées : 32 bits PPC, 64 bits PPC, 32 bits 86 et 64 bits x86_64. Voici un exemple pris dans Léopard:
Cœurs inutilisés

Et vous y voilà : les bonnes nouvelles 64 bits pour Léopard, c'est que les applications graphiques (GUI) peuvent maintenant être en 64 bits. Les applications Léopard peuvent aussi définir un ordre de préférence des architectures, et une version minimum de l'OS pour chaque architecture. Toutes ces vertus 64 bits sont dans un OS unique : il n'y a pas de version spéciale 64 bits. Léopard est un système d'exploitation, qui fait tourner les deux types d'applications : 32 bits et 64 bits.

Il n'y a pas de "mode mixte" pour Léopard. Chaque processus est soit 32 bits, soit 64 bits. Comme un processus 64 bits ne peut pas charger de greffons 32 bits, (et vice versa), il va y avoir une période de transition importante, qui repose beaucoup sur les greffons (je n'envie pas les développeurs chez Adobe..., et c'est encore pire pour eux, comme vous allez le voir bientôt).

Apple en est arrivé à un 64 bits qui s'applique à tout, à deux exceptions importantes près. Le noyau, d'abord, qui reste en 32 bits pour assurer la compatibilité avec les pilotes existants. La seconde exception est une histoire un peu triste, ou peut-être pleine d'espoir. A vous de décider.

Ce brave nouveau monde 64 bits

A la session "Etat de l'union de la HiToolbox", à la WWDC de 2006, fut montrée une diapo intitulée "le futur de la HiToolbox". C'est rarement bon signe quand la phrase "le futur de (une technologie donnée)" apparaît sur une diapo à la WWDC.

Pour ceux qui ne le savent pas, HiToolbox est la partie la plus importante et la plus récente de l'API connue sous le nom de Carbon. Le présentateur de cette session commença par dire la chose suivante, que je vous livre sous forme audio pour que vous puissiez apprécier l'expérience nuancée de ce grand moment :
(Note du traducteur Ndt pour les lecteurs francophones qui auront sans doute encore plus de difficulté à comprendre l'américain parlé que écrit, j'ai préféré traduire : "D'un mot, le futur de l'API HIToolbox est Cocoa" ; pour écouter le texte, cliquez sur le triangle de démarrage).


Pendant plusieurs milli-secondes, les programmeurs Carbon qui suivaient cette session ont vu leurs vies de travail s'embraser sous leurs yeux. Je dis seulement "quelques milli-secondes" parce que après cette pause agonisante si révélatrice, la phrase finissait en fait comme cela :
(Ndt reportons d'abord la phrase en anglais pour conserver l'ordre des mots : " in short, the future of HiToolbox is Cocoa... intégration" autrement dit "D'un mot, le futur de l'API HIToolbox c'est de s'intégrer à Cocoa").

L'intégration ! Oh mon dieu ! Oui, les programmeurs Carbon ont obtenu un sursis en 2006. Mais, la grande nouvelle à la WWDC de cette année là fut que les programmeurs Carbon devraient apprendre à intégrer les APIs Cocoa dans leurs applications Carbon ; cela aurait dû être un grand drapeau rouge.

Passons vite à la WWDC de 2007, cette fois à la session 64 bits, c'est l'autre chaussure qui a été perdue. Bien que plusieurs parties non graphiques de l'API Carbon qui sont partagées avec Cocoa seront supportées par le mode 64 bits dans Léopard, les portions graphiques de l'API Carbon ne le seront pas.

Hé oui, c'est (en fin de compte) la fin des applications carbon graphiques (GUI). Bien sûr on va les rencontrer encore pendant des années et des années, mais le manque de support 64 bits est une sentence de mort à long terme.

Les derniers vestiges de l'API du Macintosh original sont finalement mis à la retraite. Ils ont fait leur boulot, et on leur a donné des funérailles décentes, je pense. Une transition lente, et presque naturelle. Les bogues seront bien sûr corrigées dans les APIs 32 bits Carbon, mais aucune nouvelle caractéristique ne sera ajoutée. Toutes les nouvelles APIs graphiques dans Léopard et dans les versions futures de Mac OS X seront rajoutées comme des APIs Cocoa seulement.

La chose la plus difficile à avaler, pour les développeurs qui disposent d'importantes bases de code en Carbon (malheureux Adobe...) est peut-être qu'en fait, Apple a effectivement porté Carbon en 64 bits. Il y eut des sessions là-dessus à la WWDC de 2006, et le code est apparu dans les pré-versions de Léopard. La décision de laisser tomber le support 64 bits pour Carbon fut à l'évidence difficile à prendre, mais elle a été prise, en dépit du travail qui avait déjà été accompli.

Je pense que c'était une bonne décision. Apple a été handicapé par la nécessité de maintenir deux APIs différentes, de conserver la parité de fonctionnalités entre elles, et d'avoir à expliquer aux développeurs laquelle ils devaient choisir.

Quand il a fallu décider, Cocoa a gagné, parce que c'est l'API la plus moderne. Au début, au temps de Mac OS X 10.0, il n'était pas sûr du tout que les développeurs accepteraient d'apprendre Objective C et un nouvel ensemble d'APIs. Maintenant, en 2007, les développeurs se sont exprimés. Les seuls qui font encore du développement Carbon sont ceux avec des bases de code antérieures à Mac OS X. Apple a encouragé ces développeurs à passer à Cocoa depuis des années maintenant. Le temps est venu, d'un amour difficile.

Faire du ménage

Carbon n'est qu'un exemple. Sagement, Apple a décidé d'utiliser la transition vers 64 bits comme une occasion de faire un grand nombre de changements incompatibles avec le passé. Après tous, le 64 bits est déjà incompatible avec le passé 32 bits, donc il n'y a rien à perdre.

Dans Cocoa, les APIs dépassées n'ont tout simplement pas été portées en 64 bits. Le nouvel exécutif Objective-C est entièrement 64 bits, avec une nouvelle interface d'application binaire (ABI), avec une distribution des tâches plus rapide, des exceptions à coût zéro, et des APIs publiques pour permettre une introspection en restant au dessus de structures opaques internes. Partout dans Cocoa, les ints ont été remplacés par NSIntegers. Dans toutes les APIs graphiques, les floats ont été remplacés par CGFloats.

Quick Time a aussi reçu le "traitement Carbon". La vénérable API toute en C de Quick Time n'est pas disponible en 64 bits. La bibliothèque Cocoa QTKit est la seule solution pour Quick Time 64 bits.

Et ainsi de suite. Avec Léopard, le futur des APIs de Mac OS X est plus limpide qu'il n'a jamais été. Le futur, c'est Objective-c, Cocoa, 64 bits. Point ; pas d'hésitation, tout le monde dans le train.

Il y a une opposition permanente entre les développeurs avec des applications existantes et des savoir faire, et les vendeurs d'OS qui veulent attirer du sang nouveau, et prendre de bonnes décisions à long terme pour la plate-forme. La dernière décision à propos de Carbon 64 bits est une démonstration qu'Apple a été fortement confrontée de l'intérieur, à ces problèmes.

Et en fin de compte, Apple a choisi la voie difficile au lieu de la voie facile. Je pense que ce sera payant, bien que les conséquences à court terme puisse être moroses. Après tout, observez seulement combien de temps cela prend d'obtenir une version fonctionnant sur Intel de Microsoft Office pour le Mac. Pouvons nous espérer une version 64 bits de Cocoa pour, disons, 2012 ? Et je n'ai aucune idée de ce que Adobe va faire pour les versions 64 bits de ses produits. Seulement pour ces deux compagnies, cela représente plusieurs millions de lignes de code en Carbon. On est sans doute parti pour des adaptations difficiles, alors, bouclez vos ceintures.