Pourquoi Windows 9x plantait-il sur les PC rapides ?

Les conflits entre les versions 9x de Windows et le matériel « moderne » de chaque époque sont beaucoup plus profonds qu'on ne l'imagine. Même lorsque les fabricants insistaient en déclarant que leurs produits avaient été « optimisés » pour les systèmes d'exploitation de Redmond, les erreurs que subissaient les utilisateurs étaient cryptiques et frustrantes. Ces erreurs sont devenues plus fréquentes à mesure que les processeurs gagnaient en vitesse, et aujourd'hui ces systèmes sont très difficiles à exécuter, avec ou sans virtualiseur. Michal Necasek du OS/2 Museum a décidé de découvrir pourquoi…

La promesse de compatibilité d'AMD

Si vous cherchez des images de vieux processeurs AMD K6-2, vous remarquerez un détail très particulier : le logo de Windows 95 est gravé sur le spreader. C'est censé être une garantie de compatibilité, la preuve que ces puces fonctionnent sans problème sous le système d'exploitation de Microsoft. Eh bien… disons que « garantie » et « preuve » sont des expressions très optimistes. Les « Erreurs de protection de Windows » étaient intermittentes sur les K6-2 à 350 MHz, et semi-permanentes sur les modèles plus rapides.

Le plus absurde, c'est que Microsoft et AMD ont failli se faire la guerre pour ça : Redmond voulait obtenir 35 dollars supplémentaires pour le « hotfix » (même si l'objectif réel était de pousser les utilisateurs à adopter Windows 98), et AMD a répondu en publiant son propre correctif, gratuit. Les processeurs Intel ont montré une certaine résistance au début, mais ont souffert de problèmes similaires plus tard : les versions 9x de Windows plantaient avec des processeurs « trop rapides ».

Et voilà que nous arrivons au portail du OS/2 Museum, où Michal Necasek a reçu un message d'une connaissance annonçant que Windows 3.11 for Workgroups ne fonctionnait plus dans les machines virtuelles. Les premières étapes de son enquête ont révélé que l'un des principaux facteurs déclenchant l'erreur est le processeur. Un Core i7-2600 la présentait rarement, mais avec un Ryzen 7 3800X elle devenait constante : Michal tapait « win », le logo de Windows apparaissait… et retour sous DOS.

Le reste de l'article est digne de Sherlock Holmes. En traçant le noyau de débogage de 3.11 WFW, il a constaté que c'était une erreur de division par zéro quelque part dans la section réseau. Ce « quelque part » s'est avéré être NDIS.386, avec un problème spécifique : en lisant l'heure avec la commande Get_System_Time suivie de 1 048 576 itérations de LOOP, la précision maximale est d'une milliseconde. Si c'est plus rapide que ça… le début et la fin pourraient être identiques, avec une différence de zéro, impossible à diviser. Sur un processeur de 100 MHz ou plus lent, cela n'aurait jamais posé problème, mais sur une puce à 350 MHz, c'était le chaos total.

Dans le cas de Windows 95, le problème réapparaît avec NDIS.VXD, et une logique similaire apparaissait dans IOS.VXD, ESDI_506.PDR et SCSIPORT.PDR. Pourquoi les puces Intel semblaient-elles immunisées ? En substance, à cause des différences de vitesse d'exécution du LOOP : une puce K6-2 à 350 MHz était six fois plus rapide que son équivalent en Pentium II. À mesure que les puces de Santa Clara gagnaient en vitesse, l'erreur devenait plus fréquente (par exemple, Pentium 4).

L'histoire continue avec Microsoft… étant Microsoft. L'erreur a été corrigée dans les pilotes de stockage de Windows 98 (première édition), mais dans NDIS elle était toujours là, et il en allait de même avec le correctif pour Windows 95 OSR2. Le hotfix NDIS est arrivé en 2001 (l'année des débuts de XP) et uniquement pour Windows 98 ; cependant, la fameuse Seconde Édition a éliminé tous ces problèmes à la racine.

Michal conclut son article avec une conclusion très intéressante : aucune évaluation n'aurait pu détecter le bug lorsque le code a été écrit. « Que se passe-t-il si LOOP s'exécute en moins d'une milliseconde ? » n'était pas quelque chose que les ingénieurs de l'époque avaient très haut dans leur liste de priorités.

Et il y a aussi le risque de faire des suppositions. Le marché est passé d'un Pentium à 66 MHz à un K6-2 à 350 MHz en seulement cinq ans, faisant passer le LOOP de 100 millisecondes à moins de trois. Les développeurs de logiciels ont supposé qu'un tel bond de performance ne serait pas possible, et ceux du matériel, qu'accélérer l'exécution des instructions est toujours une bonne chose.

Accédez à l'article : Cliquez ici