Tables de fonctions pour les pilotes Miniport

Les interfaces de bord supérieur 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 lors de l’inscription, auquel moment le pilote miniport informe le pilote de port de la taille de la structure de contexte dont le pilote miniport aura besoin. Le pilote de port copie la table de fonction vers un emplacement privé, alloue la structure de contexte et appelle une fonction d’initialisation dans la table de fonction, en passant un pointeur vers la structure de contexte.

De même, les pilotes de miniport audio utilisent des tables de fonctions, mais elles sont allouées de manière statique et n’ont pas besoin d’être copiées 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 fonction est toujours le premier champ du contexte, le pilote de port n’a besoin que d’un pointeur de contexte et peut accéder à la table de fonction par le biais du 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 du secteur avec COM et du corps 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 lorsque la portabilité n’est pas requise.