Tables de fonctions pour les pilotes Miniport

Les interfaces haut-bord d’un pilote miniport générique (voir terminologie audio WDM) se composent de tables de fonctions. Certains pilotes miniport non audio fournissent la table de fonctions au pilote de port pendant l’inscription, auquel moment le pilote miniport informe le pilote de port de la taille de la structure de contexte requise par le pilote miniport. Le pilote de port copie la table de fonctions à un emplacement privé, alloue la structure de contexte et appelle une fonction d’initialisation dans la table de fonctions, en passant un pointeur à la structure de contexte.

De même, les pilotes miniport audio utilisent des tables de fonction, mais ils sont alloués statiquement et n’ont pas besoin d’être copiés par le pilote de port. Le pilote de port récupère également sa mémoire de contexte (« objet ») à partir d’un pool spécifié et installe un pointeur vers la table de fonctions dans le contexte. Étant donné que le pointeur de la table de fonctions est toujours le premier champ dans le contexte, le pilote de port a uniquement besoin d’un pointeur de contexte et peut accéder à la table de fonctions via le contexte.

Cette approche a été adoptée parce que COM fournit un modèle solide, efficace et largement compris pour la création d’objets abstraits. Le modèle de pilote de miniport audio tire parti de l’expérience de l’industrie avec COM ainsi que de la littérature COM. Les objets peuvent être implémentés et utilisés en C ou C++. Le langage d’assembly peut également être utilisé, mais ne doit être utilisé que si la portabilité n’est pas nécessaire.