Ceux qui utilisaient Windows XP au début de ce siècle se souviennent peut-être à quel point il était naturel que de nombreux anciens logiciels continuent de fonctionner. Raymond Chen, ingénieur chez Microsoft, a expliqué en 2003 comment cela était possible. Dans le dossier C:WINDOWSAppPatch, Windows XP conservait une liste des problèmes de compatibilité et de leurs solutions. Ces informations étaient stockées dans un fichier binaire, ce qui permettait au système de vérifier rapidement si un programme nécessitait un traitement particulier.
Windows XP s’adaptait à chaque programme
Microsoft appelle cette base de données « Application Compatibility Database ». Lors de son lancement, le fichier Sysmain.sdb contenait environ deux cents solutions. Windows ne se limitait pas à prendre en compte uniquement le nom du fichier exécutable. La taille du fichier, la somme de contrôle, le numéro de version et la date jouaient également un rôle. Le système pouvait ainsi résoudre un problème pour une version spécifique d’un programme, sans affecter une version plus récente qui fonctionnait correctement.
Ces interventions techniques sont appelées « shims ». Il s’agit de petites fonctions intermédiaires qui s’exécutent lorsqu’un programme appelle une fonction Windows. Elles peuvent modifier une commande, changer la réponse de Windows ou exécuter elles-mêmes une action avant que la fonction d’origine n’entre en action. Certains programmes refusaient par exemple de démarrer s’ils ne reconnaissaient pas la bonne version de Windows. Grâce à une solution telle que Win98VersionLie, Windows XP pouvait se faire passer pour Windows 98 auprès d’un tel programme. L’application recevait donc des informations erronées sur le système d’exploitation, mais pouvait ainsi démarrer normalement.
Microsoft est parfois allé encore plus loin. Chen cite EmulateHeap comme l’un de ses exemples préférés. Cette solution remplaçait le gestionnaire de mémoire standard d’un programme par une copie du gestionnaire de mémoire de Windows 95. En effet, certaines anciennes applications dépendaient de la manière dont ce système réservait et libérait la mémoire. Elles pouvaient donc rencontrer des problèmes sur une version plus récente de Windows.
Il ne s’agissait d’ailleurs pas d’une approche nouvelle. Windows 95 comportait déjà un code spécial pour SimCity, après que Microsoft eut découvert que le jeu continuait à utiliser de la mémoire alors qu’il l’avait lui-même libérée. Windows reconnaissait le jeu et adaptait la gestion de la mémoire afin qu’il ne plante pas immédiatement. Plutôt que d’imposer un message d’erreur aux utilisateurs, Microsoft s’efforçait donc de maintenir le logiciel en état de fonctionnement.
Continuer à assurer la prise en charge des anciens logiciels
Cette compatibilité présentait également un inconvénient. Certaines solutions perpétuaient des comportements obsolètes, même lorsque ceux-ci étaient moins sûrs. Ainsi, un mode de compatibilité pouvait permettre à des programmes de charger des fichiers DLL selon d’anciennes règles Windows, qui offraient moins de protection que les paramètres plus récents. Microsoft a agi ainsi délibérément pour les logiciels qui, sans cela, ne fonctionnaient plus.
Chen décrit cette approche comme une « compatibilité bug par bug » : Windows tenait compte non seulement des fonctionnalités des anciens programmes, mais parfois aussi de leurs erreurs et de leurs particularités. Cette technique avait toutefois ses limites. Les shims ne pouvaient intervenir qu’au sein du processus d’un programme et n’offraient aucune solution pour les pilotes incompatibles fonctionnant au niveau du noyau.
Pourquoi tant d’efforts pour des logiciels qui étaient parfois tout simplement mal conçus ? Parce qu’un seul programme indispensable pouvait bloquer une mise à niveau complète de Windows. Chen a expliqué comment les entreprises dépendaient d’applications internes, par exemple des logiciels en Visual Basic dont le développeur d’origine avait entre-temps quitté l’entreprise. Si un tel programme ne fonctionnait pas sous Windows XP, une entreprise pouvait se retrouver confrontée à des coûts supplémentaires élevés, voire ne plus pouvoir passer au nouveau système.
Microsoft a donc continué à enrichir la base de données de compatibilité pendant des années. En avril 2011, près de dix ans après le lancement de XP, la société a encore publié une mise à jour pour le fichier Sysmain.sdb. Entre-temps, de nombreuses solutions avaient été intégrées dans des fichiers DLL distincts situés dans le dossier AppPatch, afin que les fichiers principaux de Windows ne soient pas encombrés par toutes sortes d’exceptions.
La réputation de Windows XP en tant que système d’exploitation sur lequel presque tout fonctionnait n’était donc pas entièrement due au logiciel lui-même. En coulisses, Microsoft déployait beaucoup d’efforts pour assurer la compatibilité des anciens programmes, même lorsque ceux-ci ne se comportaient pas comme prévu. Heureusement, les utilisateurs n’en voyaient rien : il leur suffisait de double-cliquer sur un programme pour qu’il fonctionne. C’est précisément ce qui rendait la compatibilité de XP si exceptionnelle.
