Architecture Gestionnaire de périphériques Windows Media
Windows Media Gestionnaire de périphériques permet à une application ou à un plug-in de communiquer avec un appareil. Les applications peuvent demander des métadonnées d’appareil, énumérer et explorer les appareils attachés, et envoyer ou recevoir des objets (dossiers, fichiers, playlists, etc.). Windows Media Gestionnaire de périphériques fournit une API unique à l’application appelante, quel que soit le type d’appareil appelé (MTP ou classe de stockage de masse, fournisseurs de services basés sur la version 10 ou fournisseurs de services basés sur des versions antérieures de Windows Media Gestionnaire de périphériques).
Windows Media Gestionnaire de périphériques joue le rôle d’intermédiaire pour les trois principaux composants du système : l’application, qui effectue des demandes (pour des informations, pour lire ou écrire des données, etc.), un fournisseur de contenu sécurisé, qui est un composant qui gère la communication avec des fichiers protégés par DRM, et un fournisseur de services, qui reçoit les demandes de l’application et communique avec l’appareil pour effectuer ces demandes. L’application et le fournisseur de services sont basés sur le Kit de développement logiciel (SDK) Windows Media Gestionnaire de périphériques.
Le diagramme suivant montre comment une application de bureau communique avec un appareil à l’aide de Windows Media Gestionnaire de périphériques 11.
Le diagramme précédent montre une application communiquant avec quatre types d’appareils différents, chacun avec son propre fournisseur de services. Chaque fournisseur de services est conçu pour communiquer avec un type spécifique d’appareil ; ce diagramme montre les trois fournisseurs de services fournis par Microsoft (pilotes de classe générique pour les appareils de classe de stockage de masse, les appareils RAPI et les appareils MTP), ainsi qu’un fournisseur de services personnalisé pour un appareil propriétaire créé par un tiers. Lorsqu’un appareil se connecte, Windows Media Gestionnaire de périphériques instancie une instance du fournisseur de services inscrit pour cet appareil. Les fournisseurs de services obtiennent des demandes de l’application via Windows Media Gestionnaire de périphériques interfaces qu’ils implémentent, utilisent les pilotes appropriés pour communiquer avec l’appareil et retournent les résultats appropriés. La communication entre le fournisseur de services et l’appareil est en dehors du domaine de Windows Media Gestionnaire de périphériques.
Les fournisseurs de services sont invisibles pour l’application ; une application ne voit qu’une liste d'« appareils », car Windows Media Gestionnaire de périphériques expose un ensemble standard de méthodes et d’interfaces pour tous les appareils. Si un fabricant crée un fournisseur de services personnalisé, il doit gérer toutes les méthodes de Gestionnaire de périphériques Windows Media standard pour que les applications puissent utiliser l’appareil.
Ce diagramme montre également un module fournisseur de contenu sécurisé (SCP). Ce module est chargé de gérer le contenu protégé par la gestion des droits numériques (DRM). Microsoft fournit un module SCP qui peut gérer les fichiers WMA et WMV protégés par DRM. Si une application ou un appareil a l’intention de gérer d’autres formats protégés, il doit fournir son propre module SCP. Ni l’application ni le fournisseur de services ne traitent directement le SCP.
L’application et le fournisseur de services sont basés sur windows Media Gestionnaire de périphériques, qui achemine les appels entre l’application et le fournisseur de services approprié pour un appareil ; le fournisseur de services est chargé de communiquer directement avec l’appareil. Windows Media Gestionnaire de périphériques effectue certaines actions (telles que l’énumération des appareils connectés, le routage des appels et la gestion de la vérification des composants). Toutefois, la majeure partie du travail est effectuée par le fournisseur de services, qui reçoit les demandes de l’application et communique avec l’appareil.
Une application basée sur Windows Media Gestionnaire de périphériques peut communiquer avec des appareils et des fournisseurs de services basés sur des versions antérieures de Windows Media Gestionnaire de périphériques. Toutefois, ces appareils plus anciens seront exécutés via des composants de la série 9 (non affichés) et ne prendront pas en charge les fonctionnalités les plus récentes, en particulier la gestion des droits numériques plus avancée. Technologie.
Architecture d’un appareil
Le diagramme suivant montre une hiérarchie simplifiée d’appareils et de stockages, telle qu’elle est vue par une application utilisant Windows Media Gestionnaire de périphériques.
Le diagramme précédent montre une version simplifiée d’un lecteur flash connecté, comme le montre une application Windows Media Gestionnaire de périphériques. Le lecteur flash a des attributs et des propriétés, tels qu’un numéro de série et des configurations de format prises en charge. Un enfant immédiat de l’appareil flash est l’objet de stockage racine, qui contient un dossier, qui contient lui-même une image et une chanson.
Une application énumère les appareils attachés en appelant une méthode d’énumération exposée par l’interface IWMDeviceManager racine. Les appareils sont représentés par une interface IWMDMDevice (ou une interface dérivée). Cette interface expose des méthodes pour récupérer le nom de l’appareil, les fonctionnalités de format, le numéro de série, etc., ainsi qu’une méthode qui énumère les stockages sur l’appareil. Dans Windows Media Gestionnaire de périphériques, un stockage est n’importe quel type d’objet sur l’appareil, qu’il s’agisse ou non d’un objet blob réel de données. Par exemple : les fichiers audio, les fichiers texte, les dossiers, les playlists stockées sous forme de fichiers et les playlists stockées en tant que métadonnées sont tous considérés comme des stockages, même si les dossiers et les éléments de métadonnées ne représentent probablement pas un fichier physique. Le type (ou format) d’un stockage peut être récupéré en appelant GetAttributes (ou GetMetadata, en demandant le format du stockage).
Les stockages sur un appareil sont stockés hiérarchiquement et tous les appareils disposent d’un stockage racine. Chaque stockage peut contenir zéro ou plusieurs objets enfants, énumérés en appelant la méthode IWMDMStorage::EnumStorage de ce stockage.
Notez que chaque stockage du diagramme a des attributs et des métadonnées associés (toutes les valeurs ne sont pas affichées). Les attributs sont simples, les informations booléennes décrivant souvent des informations de gestion ou de navigation (telles que « a des dossiers » ou « peut supprimer »), tandis que les métadonnées peuvent être des valeurs de chaîne, des nombres ou des informations complexes (telles que les fonctionnalités de rendu). Les attributs sont décrits par un ensemble assez limité d’indicateurs définis par le SDK et récupérés en appelant IWMDMStorage::GetAttributes ou IWMDMStorage2::GetAttributes2. Les valeurs de métadonnées sont récupérées par un nom unique ; Le Kit de développement logiciel (SDK) définit un certain nombre de valeurs de métadonnées que les appareils doivent prendre en charge, mais les appareils peuvent définir leurs propres constantes de métadonnées. Toutefois, si un appareil ou un fournisseur de services définit une nouvelle constante de métadonnées, les applications ne pourront pas demander ou définir cette valeur, sauf si les développeurs d’applications étaient au courant de cette nouvelle constante. Un fournisseur de services doit prendre en charge IWMDMStorage3 ou version ultérieure pour prendre en charge la récupération ou la définition de métadonnées. Pour plus d’informations, consultez Obtention et définition des métadonnées et des attributs.
Fournisseurs de services
Le fournisseur de services joue le rôle d’intermédiaire entre l’application et l’appareil. Le fournisseur de services étant invisible pour le développeur d’applications, un développeur d’applications n’a pas besoin de savoir quoi que ce soit sur le développement d’un fournisseur de services. Toutefois, c’est le fournisseur de services qui effectue le travail de communication avec un appareil.
Un fournisseur de services est une DLL COM basée sur Windows Media Gestionnaire de périphériques qui reçoit les demandes d’une application et communique avec l’appareil pour les exécuter. La communication avec l’application de bureau est médiée par Windows Media Gestionnaire de périphériques ; la communication avec l’appareil est sous le contrôle du fournisseur de services.
Un fournisseur de services reçoit des demandes de l’application pour énumérer le contenu de l’appareil, les demandes de fonctionnalités de l’appareil, les demandes de lecture ou d’écriture de données, etc. Il doit connaître la conception d’un appareil suffisamment bien pour pouvoir envoyer des commandes dans le format et le protocole appropriés. Il doit également être en mesure de masquer les exigences spécifiques de l’appareil, telles qu’une extension de fichier requise pour les playlists, afin que les applications n’ont pas besoin de connaître ces exigences pour utiliser l’appareil.
Microsoft fournit un certain nombre de fournisseurs de services pour les types d’appareils standard, notamment les appareils MTP génériques, les appareils de classe de stockage de masse et les appareils RAPI. La seule raison pour laquelle un concepteur d’appareil doit avoir besoin de créer un fournisseur de services personnalisé est si un appareil a des exigences de stockage de données spécifiques ou inhabituelles que les fournisseurs de services standard ne gèrent pas. Par instance, si les fichiers doivent être stockés à des emplacements spécifiques et que le système d’exploitation de l’appareil ne gère pas cela automatiquement.
Lorsqu’un appareil est connecté à l’ordinateur, le système d’exploitation crée un instance du fournisseur de services approprié pour chaque application Windows Media Gestionnaire de périphériques. Si une deuxième application Windows Media Gestionnaire de périphériques démarre, une deuxième instance du fournisseur de services est chargée. Toutefois, chaque fournisseur de services peut gérer plusieurs appareils. Le diagramme suivant illustre ce point.
Le diagramme précédent montre deux applications différentes qui communiquent avec deux appareils MTP. Les appareils utilisent la même classe de fournisseur de services, mais chaque application a ses propres instance du même fournisseur de services. Chaque fournisseur de services instance communique avec les appareils. Les différentes instances du fournisseur de services ne se connaissent pas.
De nombreuses méthodes d’application ont une méthode de fournisseur de services nommée correspondante. Lorsque l’application appelle une méthode, Windows Media Gestionnaire de périphériques achemine l’appel vers la méthode correspondante sur le fournisseur de services (bien qu’elle puisse d’abord effectuer d’autres actions internes). Par exemple, lorsque l’application appelle IWMDMDevice3::GetProperty, Windows Media Gestionnaire de périphériques achemine cet appel vers l’implémentation d’IMDSPDevice3::GetProperty du fournisseur de services. (La plupart des interfaces d’application commencent par IWMDM, et l’interface de fournisseur de services correspondante commence par IMDSP). Le fournisseur de services est censé gérer cet appel de méthode et retourner un résultat approprié.
Une application n’explore ni ne communique avec un appareil directement (sauf si elle appelle IWMDMDevice3::D eviceIoControl ou IWMDMStorage::SendOpaqueCommand) ; l’application communique avec le fournisseur de services, qui doit représenter un appareil de la manière la plus logique et la plus simple possible. Lorsque l’application demande des informations sur l’appareil ou énumère des objets sur l’appareil, le fournisseur de services interroge l’appareil de manière appropriée et acquiert et retourne les informations appropriées. Il peut exposer le fichier organization sur l’appareil différemment de la façon dont il est physiquement stocké sur l’appareil, si cela est approprié. Quelle que soit l’exposition de l’appareil, il doit être cohérent et logique pour permettre à l’application de trouver ce dont elle a besoin et de gérer les commandes qu’elle envoie. Un bon fournisseur de services masquera les particularités propres à l’appareil. Par exemple, si l’appareil stocke physiquement une playlist en tant que fichier avec une extension de fichier personnalisée, le fournisseur de services doit ajouter cette extension automatiquement lorsque l’application crée une playlist sur l’appareil ; il ne doit pas s’attendre à ce que l’application connaisse l’extension appropriée lors de la création d’un objet de playlist.
Les fournisseurs de services s’exécutent dans le processus de l’application appelante. La seule exception à cela est le fournisseur de services MTP, qui s’exécute dans son propre processus. Pour cette raison, il existe un risque qu’un fournisseur de services bloqué provoque le blocage de l’application appelante. Par conséquent, les fournisseurs de services doivent être conçus pour être robustes et empêcher les blocages, et les applications doivent être conçues pour éviter le blocage si un appel de méthode particulier ne retourne pas rapidement.
Rubriques connexes