Windows XP doit une partie de sa réputation à sa capacité à lancer d’anciens logiciels sans broncher. Cette compatibilité logicielle ne reposait pas seulement sur la conservation d’anciennes API : Microsoft avait aussi préparé des corrections ciblées pour les applications récalcitrantes. Certaines recevaient même, en quelque sorte, une version arrangée de la réalité.
Windows XP et la rétrocompatibilité : une transition à sécuriser
Lancé le 25 octobre 2001, Windows XP a rapproché le grand public de l’architecture Windows NT. Le changement apportait un noyau différent et une gestion plus robuste de la mémoire, mais risquait aussi de casser des logiciels conçus pour Windows 95, 98 ou Me.
Pour éviter que les utilisateurs se retrouvent avec des programmes inutilisables, Microsoft a mis en place l’Application Compatibility Database. Installée dans le système, cette base associait des applications précises à des réglages conçus pour contourner leurs incompatibilités.
Les informations étaient stockées dans des fichiers binaires .sdb, capables d’identifier une version précise d’un programme. Windows pouvait tenir compte du nom, de la taille, de la version ou d’une empreinte du fichier : une mise à jour corrigée n’avait donc pas forcément besoin du même traitement.
Les couches de compatibilité et les correctifs ciblés
Une fois le logiciel identifié, Windows pouvait appliquer un shim, autrement dit une couche logicielle placée entre le programme et certaines fonctions du système. Elle interceptait des appels API et pouvait modifier leurs paramètres ou leurs résultats avant de laisser l’application poursuivre son exécution.
Ce mécanisme n’était pas une machine virtuelle. Il ne lançait pas une copie complète de Windows 98 : il adaptait seulement quelques comportements, pour un programme déterminé, tandis que le reste du système continuait de fonctionner normalement.
Cette méthode avait un avantage concret. Elle permettait à Microsoft de corriger un défaut d’un ancien outil sans imposer le même contournement à tous les logiciels, ni modifier globalement le fonctionnement de Windows XP.
VersionLie : quand Windows XP trompait un logiciel
Certains programmes vérifiaient la version de Windows avant même d’essayer de fonctionner. Un logiciel conçu pour Windows 98 pouvait ainsi refuser XP, même si les fonctions dont il avait besoin étaient toujours disponibles. C’était une vérification rigide, mais courante à l’époque.
Les correctifs de la famille VersionLie répondaient à ce problème en présentant au programme des informations de version différentes de la réalité. L’application croyait retrouver un système connu et poursuivait son lancement. Le nom est explicite : « lie » signifie mensonge en anglais.
Ce tour de passe-passe avait ses limites. Il dépannait les clients, mais ne constituait pas une bonne pratique de développement : un logiciel devrait vérifier la présence des fonctions nécessaires, pas bloquer sur un numéro de version inattendu.
EmulateHeap : un comportement hérité de Windows 95
Les problèmes liés à la mémoire demandaient parfois des mesures plus profondes. Certains logiciels continuaient à lire une zone de mémoire après l’avoir libérée, ou dépendaient d’un résultat particulier lors d’une allocation. Ces erreurs pouvaient rester invisibles sur un ancien système, puis provoquer un plantage sous XP.
Le correctif EmulateHeap reproduisait, pour certains programmes identifiés, des aspects du gestionnaire de mémoire de Windows 95. D’après les explications de l’ingénieur Microsoft Raymond Chen, l’approche allait jusqu’à réintégrer du code de cet ancien gestionnaire dans l’environnement de compatibilité du processus.
Ce n’était pas une permission de mal programmer. C’était une réparation ciblée, parfois nécessaire pour que des logiciels déjà déployés continuent de tourner. En production, ce genre de détail séparait une migration propre d’une journée passée à diagnostiquer des plantages.
Ce que l’exemple de Windows XP dit encore aux administrateurs
La compatibilité de XP n’était pas de la magie : elle résultait d’un inventaire précis des logiciels et de corrections adaptées à leurs défauts. Ce travail explique pourquoi un programme ancien pouvait démarrer sans que l’utilisateur sache qu’un shim intervenait en coulisses.
Les mécanismes de compatibilité ont évolué dans les versions suivantes de Windows, mais l’idée reste familière : préserver l’usage quand une application dépend d’un comportement ancien. Cela ne garantit toutefois ni la sécurité ni le bon fonctionnement de tout logiciel obsolète. Le support d’un système et celui des applications sont deux sujets distincts, comme le rappelle ce point sur la fin du support de Windows 11.
| Mécanisme | Effet | Limite |
|---|---|---|
| Base .sdb | Identifie une application et sa version | Repose sur des règles ciblées |
| VersionLie | Présente une version de Windows attendue | Ne corrige pas le logiciel lui-même |
| EmulateHeap | Reproduit certains comportements mémoire anciens | Réservé à des cas particuliers |
Pour les environnements actuels, la même prudence s’impose lors d’un changement de plateforme ou d’architecture. Les difficultés des applications Windows sur ARM montrent que la compatibilité reste un travail technique, pas une promesse automatique. XP l’avait simplement rendu presque invisible à l’utilisateur.
