Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Windows Media Device Manager 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 des appareils attachés, et envoyer ou recevoir des objets (dossiers, fichiers, playlists, etc.). Windows Media Device Manager fournit une API unique à l’application appelante, quel que soit le type d’appareil appelé (classe MTP ou Stockage de masse, fournisseurs de services basés sur la version 10 ou les fournisseurs de services basés sur les versions antérieures de Windows Media Device Manager).
Windows Media Device Manager agit comme un go-between pour les trois principaux composants du système : l’application, qui effectue des demandes (pour plus d’informations, pour lire ou écrire des données, et ainsi de suite) ; 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 des 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 Device Manager.
Le diagramme suivant montre comment une application de bureau communique avec un appareil à l’aide de Windows Media Device Manager 11.
Le diagramme précédent montre une application qui communique 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 en 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 Device Manager instancie une instance du fournisseur de services inscrit pour cet appareil. Les fournisseurs de services obtiennent des demandes de l’application via des interfaces Windows Media Device Manager qu’ils implémentent, utilisent les pilotes appropriés pour communiquer avec l’appareil et retourner les résultats appropriés. La communication entre le fournisseur de services et l’appareil se trouve en dehors du domaine du Gestionnaire d’appareils Windows Media.
Les fournisseurs de services sont invisibles pour l’application ; une application ne voit qu’une liste d'« appareils », car Windows Media Device Manager 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 Standard de Windows Media Device Manager si les applications doivent pouvoir utiliser l’appareil.
Ce diagramme montre également un module SCP (Secure Content Provider). Ce module est responsable de la gestion du 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 envisage 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 du SCP.
L’application et le fournisseur de services sont basés sur Windows Media Device Manager, qui route 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 Device Manager effectue certaines actions proprement dites (telles que l’énumération des appareils connectés, le routage des appels et la gestion de la vérification des composants) ; Toutefois, la plupart du travail est effectué 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 Device Manager peut communiquer avec des appareils et des fournisseurs de services basés sur des versions antérieures de Windows Media Device Manager ; Toutefois, ces anciens appareils seront exécutés via 9 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 technologie de gestion des droits numériques plus avancée.
Architecture d’un appareil
Le diagramme suivant illustre une hiérarchie simplifiée d’appareils et de stockages, comme indiqué par une application à l’aide du Gestionnaire de périphériques Windows Media.
Le diagramme précédent montre une version simplifiée d’un lecteur flash connecté, comme indiqué par une application Windows Media Device Manager. 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 la racine IWMDeviceManager interface. Les appareils sont représentés par une interface IWMDMDevice (ou 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, et ainsi de suite, ainsi qu’une méthode qui énumère stockages sur l’appareil. Dans le Gestionnaire d’appareils Windows Media, un stockage est un 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 en tant que 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 de fichier physique. Le type (ou le 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 ont 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 dans le diagramme a des attributs et des métadonnées qui lui sont associés (toutes les valeurs ne sont pas affichées). Les attributs sont des informations booléennes simples qui décrivent souvent des informations de gestion ou de navigation (telles que « possède 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 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 n’ont pas pris connaissance 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 des métadonnées. Pour plus d’informations, consultez Obtention et définition des métadonnées et des attributs.
Fournisseurs
Le fournisseur de services agit comme un intermédiaire entre l’application et l’appareil. Le fournisseur de services est invisible pour le développeur d’applications. Par conséquent, 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, il s’agit du 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 Device Manager qui reçoit les demandes d’une application et communique avec l’appareil pour les effectuer. La communication avec l’application de bureau est médiatée par windows Media Device Manager ; 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 d’appareil, les demandes de lecture ou d’écriture de données, et ainsi de suite. Il doit connaître la conception d’un appareil suffisamment bien qu’il peut envoyer des commandes au format et au protocole appropriés. Il doit également être en mesure de masquer les exigences spécifiques à 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 afin d’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’appareils doit créer un fournisseur de services personnalisé est qu’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 exemple, si les fichiers doivent être stockés dans 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 une instance du fournisseur de services approprié pour chaque application Windows Media Device Manager. Si une deuxième application Windows Media Device Manager 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 cela.
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 sa propre instance du même fournisseur de services. Chaque instance de fournisseur de services communique avec les appareils. Les différentes instances du fournisseur de services ne sont pas conscientes les unes des autres.
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 Device Manager route l’appel vers la méthode correspondante sur le fournisseur de services (bien qu’il puisse effectuer d’abord des actions internes supplémentaires). Par exemple, lorsque l’application appelle IWMDMDevice3 ::GetProperty, Windows Media Device Manager route cet appel à l’implémentation du fournisseur de services de IMDSPDevice3 ::GetProperty. (La plupart des interfaces d’application commencent par IWMDM, et l’interface du 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 jamais ou communique directement avec un appareil (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 obtient et retourne les informations appropriées. Il peut exposer l’organisation de fichiers sur l’appareil différemment de la façon dont elle est physiquement stockée sur l’appareil, le cas échéant. Toutefois, il expose l’appareil, il doit être de manière cohérente 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 masque 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 à ceci est le fournisseur de services MTP, qui s’exécute dans son propre processus. En raison de cela, 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 le blocage, et les applications doivent être conçues pour éviter de bloquer si un appel de méthode particulier ne retourne pas rapidement.
Rubriques connexes