Portatif

Tous les pilotes doivent être portables sur toutes les plateformes matérielles prises en charge par Windows. Pour obtenir une portabilité multiplateforme, les développeurs de pilotes doivent :

• Code en C (aucune langue d’assembly).

• Interagissez avec Windows uniquement à l’aide des interfaces de programmation et des en-têtes fournis dans wdK.

Codage des drivers en C

Tous les pilotes en mode noyau doivent être écrits en C afin qu’ils puissent être recompilés avec un compilateur C compatible avec le système, relinkés et exécutés sur différentes plateformes Microsoft Windows sans réécriture ou remplacement de code. La plupart des composants du système d’exploitation sont entièrement codés en C, avec seulement de petites parties des composants HAL et noyau écrits dans le langage d’assembly, afin que le système d’exploitation soit facilement portable sur les plateformes matérielles. Vous ne pouvez pas utiliser de nombreuses constructions de langage C++ dans les pilotes en mode noyau. Vous devez donc évaluer soigneusement ces constructions. Pour plus d’informations sur les problèmes qui surviennent lorsque les pilotes incluent des fonctionnalités C++, consultez le livre blanc C++ pour les pilotes en mode noyau : avantages et inconvénients .

Les pilotes ne doivent pas s’appuyer sur les fonctionnalités d’un compilateur C compatible avec le système ou d’une bibliothèque de prise en charge C particulière si ces fonctionnalités ne sont pas garanties d’être prises en charge par d’autres compilateurs compatibles avec le système. En général, le code du pilote doit être conforme à la norme ANSI C et ne dépend pas de tout ce que cette norme décrit comme étant « définie par l’implémentation ».

Pour écrire des pilotes portables, il est préférable d’éviter :

• Dépendances sur les types de données qui peuvent varier en taille ou disposition d’une plateforme à une autre.

• Appel de n’importe quelle fonction de bibliothèque runtime C standard qui conserve l’état.

• Appel de toute fonction de bibliothèque runtime C standard pour laquelle le système d’exploitation fournit une autre routine de prise en charge.

Utilisation d’interfaces WDK-Supplied

Chaque composant exécutif Windows NT exporte un ensemble de pilotes en mode noyau prenant en charge les routines que les pilotes et tous les autres composants en mode noyau appellent. Si l’implémentation sous-jacente d’une routine de prise en charge change au fil du temps, ses appelants restent portables, car l’interface du composant de définition ne change pas.

WdK fournit un ensemble de fichiers d’en-tête qui définissent des types de données et des constantes spécifiques au système que les pilotes (et tous les autres composants en mode noyau) utilisent pour aider à maintenir la portabilité d’une plateforme à une autre. Tous les pilotes en mode noyau incluent l’un des fichiers d’en-tête du mode noyau WDK maître, Wdm.h ou Ntddk.h. Les fichiers d’en-tête maître extrayent non seulement les en-têtes fournis par le système qui définissent les types de mode noyau de base, mais également les sélections appropriées à partir d’en-têtes spécifiques à l’architecture du processeur lorsqu’un pilote est compilé avec la directive du compilateur correspondante.

Certains pilotes, tels que les pilotes miniport SCSI, les pilotes NDIS et les pilotes miniport vidéo, incluent d’autres fichiers d’en-tête fournis par le système.

Si un pilote nécessite des définitions dépendantes de la plateforme, il est préférable d’isoler ces définitions dans les instructions #ifdef , afin que chaque pilote puisse être compilé et lié pour la plateforme matérielle appropriée. Toutefois, vous pouvez presque toujours éviter d’implémenter un code compilé de manière conditionnelle spécifique à la plateforme dans un pilote à l’aide des routines de prise en charge, des macros, des constantes et des types fournis par les fichiers d’en-tête maître WDK.

Les pilotes en mode noyau peuvent utiliser des routines RtlXxx en mode noyau documentées dans wdK. Les pilotes en mode noyau ne peuvent pas appeler les routines RtlXxx en mode utilisateur.