Windows 95 a traité à part le bug de libération de mémoire de SimCity au lieu de demander à Maxis de le corriger

Windows 95 fusionnait les applications MS-DOS et Windows et faisait passer l'ensemble des API de 16 à 32 bits, et Microsoft voulait que les gens n'aient aucune raison de ne pas mettre à jour. Une raison faillit subsister : SimCity pour Windows 3.x, dont l'auteur Jon Ross avait accidentellement laissé un bug qui lisait de la mémoire qu'il venait de libérer. Sous Windows 3.x, tout fonctionnait bien parce que la mémoire ne disparaissait jamais ; sur les bêtas de Windows 95, le jeu plantait. Avec plus de 5 millions d'exemplaires vendus, SimCity devait fonctionner sans le moindre accroc.

Microsoft traqua le bug et ajouta au code de Windows 95 une routine qui recherche SimCity ; si elle trouve le jeu en cours d'exécution, elle fait tourner l'allocateur de mémoire dans un mode spécial qui ne libère pas immédiatement la mémoire. SimCity n'était pas seul : l'Administrateur de compatibilité du Windows ADK montre la base de correctifs par application. Windows NT, en détectant les fichiers généralement installés avec Final Fantasy VII, applique un correctif littéralement nommé « Win95VersionLie » — qui se contente de dire au jeu qu'il tourne sous Windows 95 — tandis que Dungeon Keeper reçoit des corrections de chemins de fichiers liées à des fichiers comme « Horny.tif ».

L'obsession était institutionnelle. Raymond Chen a documenté en 2005 que le responsable du développement de Windows 95 avait conduit un pick-up jusqu'au magasin Egghead Software local et acheté un exemplaire de chaque programme PC du magasin ; chaque développeur se voyait confier jusqu'à deux programmes à installer, exécuter et documenter pour en relever les bugs, et les testeurs pouvaient garder ce qu'ils avaient terminé. Mike Perry, ancien directeur créatif chez Maxis, a noté plus tard que Ross était allé travailler chez Microsoft après avoir quitté Maxis.

Les cales de compatibilité : le système d'exploitation reconnaît une application précise et infléchit discrètement son propre comportement — libérations retardées, mensonges sur la version — afin que l'ancien binaire ne sache jamais que quelque chose a changé.

La réussite d'une mise à jour de système d'exploitation dépend de son catalogue d'applications ; les utilisateurs n'achèteront pas un OS qui casse les jeux et les outils qu'ils possèdent déjà.

Corriger chaque éditeur tiers était impossible, donc les cales ont permis à Microsoft de réparer la compatibilité sans toucher au code de quiconque.

Détecter les applications par leur nom ou par les fichiers installés rendait chaque correctif chirurgical au lieu de modifier le comportement pour tout.

Les tests massifs de vrais logiciels du commerce ont transformé les incompatibilités inconnues en une liste documentée et assignable avant le lancement.

La rétrocompatibilité peut s'acheter application par application : émuler les bugs d'une ancienne plateforme — même ses erreurs de mémoire — supprime toute excuse de ne pas mettre à jour et brise le problème de l'œuf et de la poule logiciel.

Joel Spolsky, qui a raconté à nouveau l'histoire de SimCity en 2000, a qualifié cela de moyen de briser le problème de l'œuf et de la poule des systèmes d'exploitation : « fournir un mode de rétrocompatibilité qui livre soit un camion de poules, soit un camion d'œufs, selon le point de vue, puis se laisser aller et empocher les bénéfices. » La base de cales par application a survécu à Windows 95 et reste consultable dans le Windows Assessment and Deployment Kit.