Portable
Tous les pilotes doivent être portables sur toutes les plateformes matérielles prises en charge par Windows. Pour obtenir la portabilité multiplateforme, les enregistreurs de pilotes doivent :
Code en C (pas de langage d’assembly).
Interagissez avec Windows en utilisant uniquement les interfaces de programmation et les en-têtes fournis dans le WDK.
Codage des pilotes 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 système, relinkés et exécutés sur différentes plateformes Microsoft Windows sans réécriture ni remplacement de code. La plupart des composants du système d’exploitation sont entièrement codés en C, avec seulement de petits morceaux des composants HAL et du noyau écrits en langage d’assembly, de sorte que le système d’exploitation est 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 ou d’une bibliothèque de prise en charge C compatible avec le système si ces fonctionnalités ne sont pas garanties d’être prises en charge par d’autres compilateurs compatibles système. En général, le code du pilote doit être conforme à la norme ANSI C et ne dépend pas de ce que cette norme décrit comme « défini 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 en disposition d’une plateforme à l’autre.
Appel de toute fonction de bibliothèque runtime C standard qui conserve l’état.
Appel de n’importe quelle 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.
Le 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 wdK en mode noyau les master, Wdm.h ou Ntddk.h. Les fichiers d’en-tête master extraient 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 de compilateur correspondante.
Certains pilotes, tels que les pilotes miniport SCSI, les pilotesNDIS et lespilotes 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 #ifdef instructions, 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 du 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 WDK master.
Les pilotes en mode noyau peuvent utiliser des routines RtlXxx en mode noyau qui sont documentées dans le WDK. Les pilotes en mode noyau ne peuvent pas appeler des routines RtlXxx en mode utilisateur.