La vie secrète de WindowsLe pouvoir des bogues

Raymond Chen

Dans Windows 95 , vous pouviez aller sur la page Dépannage et sélectionner Désactiver les validations de tampon synchrone. Mais savez-vous ce que faisait cette case ? Ou pourquoi elle faisait ce qu'elle faisait ?

Le comportement normal de la fonction de validation de MS-DOS® consistait à vider sur le disque toutes les données qui n'étaient pas écrites, et à attendre que l'écriture des données ait été validée avant le retour. Une fois l'option Désactiver les validations de tampon synchrone cochée, l'appel était immédiatement retourné, au lieu d'attendre que les données soient écrites. Cela était bien sûr une violation de la spécification fonctionnelle qui nécessite que l'appel ne soit pas retourné avec que les données n'aient été écrites. Cela augmentait le risque de ce que l'article 139669 de la Base de connaissance qualifie avec euphémisme de « problèmes d'intégrité du fichier », puisqu'il faisait croire au programme de vidage que les données étaient bien sur le disque alors que ce n'est pas le cas.

Un programme de base de données peut utiliser la fonction de validation pour établir des points auxquels l'état du fichier sur le disque est en accord avec ce que le programme s'attend à trouver sur le disque. Si l'ordinateur perd de la puissance pendant une mise à jour, le programme de la base de données peut utiliser les informations enregistrées au dernier point de validation pour rétablir l'intégrité de la base de données. Si la validation répondait immédiatement, avant que la validation ne soit terminée, ce point de contrôle d'intégrité était perdu. Par conséquent, votre base de données devenait corrompue.

Pourquoi cette option était-elle disponible si les conséquences étaient si terribles ? En voici la raison : un bogue dans Windows® 3.11.

Figure 1** Activation d'un comportement bogué dans Windows Server 2003 **(Cliquer sur l'image pour l'agrandir)

Windows 3.11 proposait un « accès aux fichiers 32 bits », qui était une implémentation 32 bits de l'interface E/S du fichier de niveau inférieur. Mais l'implémentation de la fonction de validation contenait un bogue qui ignorait en fait les requêtes de vidage des tampons de fichier. Si vous preniez un programme qui vidait ses tampons de fichier et que vous le faisiez fonctionner sur Windows 3.11, l'appel de vidage n'avait aucun effet. Par conséquent, si vous perdiez de la puissance au mauvais moment, vous vous retrouviez avec une base de données corrompue.

L'équipe qui travaillait sur le système de fichiers de Windows 95 a réparé ce bogue, mais de nouveaux rapports sur les bogues ont commencé à apparaître. Le programme des comptes fournisseurs d'un utilisateur commençait à fonctionner vraiment lentement. Ensuite, c'était au tour d'un programme de base de données d'un autre utilisateur de tourner au ralenti. Qu'est-ce qui se passait ?

On s'est rendu compte que ces programmes faisaient sans arrêt des appels de vidage. Les programmeurs ont remarqué que ces appels de vidage étaient vraiment rapides sur Windows 3.11 : ils en ont donc mis un peu partout dans leurs programmes. Écrire un octet, vider. Écrire une chaîne, vider. Puisque les vidages étaient si rapides, l'application validait les données sur le disque après chaque opération, sans apparente dégradation des performances. Mais une fois que Windows 95 avait réparé le bogue, ces programmes ont commencé à fonctionner très lentement puisque les appels de validation se mettaient à vraiment fonctionner.

Bien sûr, si l'équipe du système de fichiers n'avait rien fait, ces programmes auraient continué à fonctionner lentement et les utilisateurs en auraient directement conclu que le problème venait de Windows 95. Ils se seraient empressés de dire à tout le monde : « Windows 95 marche comme un unijambiste ». D'un autre côté, si le système de fichiers était revenu à l'ancien comportement de Windows 3.11, les programmeurs auraient réintroduit un bogue qui pouvait provoquer ces fameux « problèmes d'intégrité du fichier ».

Ils ont finalement décidé de laisser la correction du bogue, mais d'ajouter une case à cocher (bien cachée dans la page Dépannage), pour retourner au comportement de Windows 3.11 pour les utilisateurs qui faisaient tourner des programmes sujets aux erreurs en raison de la correction du bogue.

Il s'est trouvé que l'histoire s'est répétée. Dans Windows Server® 2003, les gens de l'interface E/S ont découvert un bogue à cause duquel des requêtes appelées Forced Unit Access (FUA) perdaient leur balise FUA et fonctionnaient comme une E/S normale. C'est une version moderne du fait d'ignorer les requêtes de vidage ! Ils ont réparé le bogue mais ont laissé une option qui permet de revenir à l'ancien comportement bogué. La version Windows Server 2003 de cette case à cocher est appelée « Activer les performances avancées », mais vous savez maintenant ce qu'elle signifie vraiment : « Restaurer l'ancien comportement bogué ».

Raymond Chen possède un site Web, The Old New Thing, ainsi qu'un livre portant le même nom (éditions Addison-Wesley, 2007) qui traitent de l'historique de Windows et de la programmation Win32. Il ne passe pas son temps à chercher... le petit bogue.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.