le plan de Microsoft pour migrer les développeurs de Win32 vers les Windows Apps
Après les principales caractéristiques et ambitions de Core OS, nous approfondissons les détails techniques de Win32, ses évolutions et ce qui attend les développeurs. Contrairement aux tentatives passées de Microsoft dans ce domaine, la nouvelle approche est nettement plus «douce». La migration progresse, mais il reste des obstacles.
Dans nos articles précédents, nous avons expliqué comment Core OS représenterait un nouveau chapitre dans l'histoire de Windows, offrant une solution flexible aux problèmes actuels. Microsoft est en effet coincé depuis longtemps entre les anciennes interfaces de programmation, largement utilisées mais peu sécurisées, et les nouvelles, beaucoup plus sûres mais aussi plus limitées.
Près de dix ans d'errance, rythmés par des échecs retentissants comme Windows RT, auront déplacé le plan initial vers un projet beaucoup plus intégré où, normalement, les développeurs devraient trouver leur chemin.
Notre dossier sur Core OS:
Le problème posé par Win32
Qu'est-ce que Win32 en premier? Il s'agit d'un ensemble d'interfaces de programmation, exposant les développeurs à une base standardisée de fonctions exploitables. Pour afficher une fenêtre par exemple, il n'est pas question de réécrire le code d'une fonction jugée triviale.
Comme mentionné dans notre article précédent, Win32 est apparu pour la première fois avec Windows NT en 1993, pour suivre l'évolution technique vers 32 bits. Les anciennes API ont été regroupées dans le groupe Win16. Les utilisateurs connaissent probablement les trois principales bibliothèques Win32: Kernel32.dll, User32.dll et GDI32.dll. Chacun présente des fonctions essentielles.
- Kernel32: fonctions de base du noyau, pour les appels directs à l'API du noyau NT (API native).
- GDI32: fonctions graphiques de base (dessins, polices, pixellisation …)
- User32: fonctions de l'interface graphique (shell, dialogues et menus)
Il y a aussi le réseau (ws2_32), la manipulation du registre (advapi32), les dialogues classiques (comctl32) ou encore la gestion COM (ole32).
Au fil du temps, le nombre de fonctions Win32 a décuplé. Cette augmentation était au carrefour des demandes des développeurs et de la direction que Microsoft souhaitait donner à l'évolution de Windows. Il devait également pouvoir interagir avec un nombre croissant de produits.
Mais Win32 a été construit dans les années 90, avec les techniques et les préoccupations du moment. Il ne s'agissait pas tant d'une question de sécurité que de fournir rapidement ce qui était nécessaire. Par ailleurs, Microsoft souhaitait donner rapidement accès aux API de composants qui, s'ils étaient liés à Windows, restaient indépendants: Internet Explorer, DirectX, Office, etc. Ce sont les fameuses API COM.
Le modèle choisi a largement étendu Win32, exposant tous les composants importants de COM. Il devait créer un environnement dans lequel les logiciels pouvaient gambader avec bonheur. C'était certainement le cas – et c'est encore en partie – mais il y avait un prix à payer: les logiciels malveillants. Même si le problème a commencé principalement avec Windows 95, il n'a fait qu'augmenter, jusqu'à la «crise» sous Windows XP, entraînant un Service Pack 2 (qui a incorporé pour la première fois un incendie) et retardant Vista.
La situation était d'autant plus grave que les comptes créés sous Windows étaient par défaut en droits d'administrateur, sans aucun verrouillage avant d'effectuer des actions importantes, comme l'installation d'un programme. On se souvient de Sasser, si répandu qu'il suffisait de laisser connectée à Internet une machine Windows XP non mise à jour pour être infectée en quelques minutes, grâce à une faille de sécurité.
Il a donc fallu réformer en profondeur l'architecture du système.
Commentaires récents