Au cœur de Windows Vista

Windows Driver Model : un modèle de pilotes qui date

Ceux qui n’ont jamais eu de problème lors de l’installation d’un pilote ne doivent pas être nombreux. Qu’il s’agisse d’écrans bleus surgissant aléatoirement, que ce soit sous Windows 9x (qui ne connait pas VMM.VXD), ou Windows 2000/XP, ou du blocage pur et simple de la machine, vous en avez au moins entendu parler. Les responsables, vous les connaissez déjà, ce sont les pilotes, de petits programmes qui permettent au système d’exploitation (en l’occurrence Windows) de communiquer avec du matériel.

Il nous restera au moins l'écran de veille BSOD

Les différents systèmes Windows supportent de nombreux périphériques et gèrent plus de 30 000 pilotes dont certains datent de plus de dix ans. Ces versions ont acquis dans le temps la mauvaise réputation d’être instables. Mais selon Microsoft, plus de 85 % des plantages de Windows XP sont dus à des pilotes mal programmés. D’ailleurs, une majorité des développeurs estime que le modèle de pilotes actuel est trop complexe, et Microsoft l’a compris et a décidé de se défaire de son modèle introduit avec Windows 98, le Windows Driver Model, pour le remplacer par le Windows Driver Framework.

vista installation driver

Bref historique du WDM : de Windows 98 à Windows XP

Le WDM a été conçu à l’origine pour standardiser l’écriture des drivers pour les pilotes de Windows 98 et 2000 et aussi réduire le nombre de lignes de code nécessaires. Si un pilote WDM ne peut pas s’exécuter sous Windows 95 ou NT4 par exemple, le modèle indique cependant qu’il pourra aussi bien s’exécuter sous Windows 98 que 98 SE, ME, Windows 2000, XP ou 2003 car il est prévu que des pilotes soient compatible (sources et binaires) entre les différents systèmes. Si ce cas est rare entre la famille 9x et NT5, on le retrouve souvent entre Windows 2000 et XP. Plus précisément, WDM a été conçu pour permettre la compatibilité ascendante mais pas la rétro compatibilité. En résumé, un pilote conçu pour Windows 98 a des chances de fonctionner avec Windows 2000, mais il ne profitera pas des nouvelles fonctions du WDM introduites dans le système supérieur ; l’inverse est par contre impossible.

Un modèle obsolète

A l’heure actuelle, ce modèle est jugé particulièrement complexe et l’écriture de drivers « simples » requiert plusieurs milliers de lignes de code, dont au moins 2 000 pour la prise en charge du Plug and Play et de la gestion de l’énergie. Pour communiquer avec le système, le pilote passe par une interface que l’on appelle communément device-driver interface ou DDI. De même, ces DDI sont très proches du noyau et leur modification implique souvent une recompilation des pilotes les utilisant. Ces DDI sont critiquées par les développeurs qui les trouvent trop compliquées à utiliser lorsqu’il s’agit de gérer le Plug and Play, les entrées / sorties asynchrones ou la gestion de l’énergie. Implémenter la gestion de l’énergie et du PnP oblige à gérer une centaine d’états du périphérique concerné. Lors de la création de son modèle, Microsoft n’avait pas prévu tous ces développements de drivers annexes, et, afin de garantir des performances optimales, les DDI ont été rattachées au noyau. L’inconvénient, vous l’aurez compris, c’est qu’un driver instable, peut, à travers une interface, corrompre le système et le bloquer. Windows supporte actuellement plus de dix modèles de miniport (un pilote miniport est un pilote générique qui rempli un certain nombre de fonctions de base pour les périphériques USB, SCSI, réseau ou audio ; ces pilotes sont censés être compatibles au niveau des sources et des binaires avec Windows 98 et 2000). Ces modèles ont été créés pour simplifier la vie des développeurs mais le choix d’un modèle plutôt qu’un autre n’est pas toujours évident et la situation se complique lorsqu’il s’agit d’un périphérique multifonction. Encore une fois, la support du PnP et de la gestion de l’énergie se trouve compliquée par le fait que chaque modèle expose ces fonctions de manières différentes.

kmdf vista

Terminons par le point le plus négatif pour l’éditeur, et sur lequel il a vraisemblablement beaucoup travaillé : la majorité des pilotes ne peuvent être exécutés qu’en espace noyau, ce qui veut dire que ce portions de code sont traitées comme une partie du noyau et ont accès à l’espace d’adressage système. Un plantage du pilote, et c’est le crash pour le système entier. Pourtant, un nombre conséquent de périphériques n’ont pas besoin de cet accès privilégié et devraient donc être exécutés en espace utilisateur. Mais là encore, le modèle actuel ne facilite pas la tâche des utilisateurs, puisqu’il n’existe aucun support pour guider les programmeurs désireux de programmer un pilote en espace utilisateur.