Comment trouvez-vous les interfaces d'un COM sans typelib?

Question

Est-il possible de trouver toutes les interfaces (classes, paramètres, ect ..) normalement enregistrées avec TypeLib du Component Object Model (COM) même si la TypeLib est complètement vide? Si oui, comment vous y prendrez-vous? Je crois qu'un autre terme pour cela est un "COM anonyme". Je suis sûr que des interfaces accessibles existent pour ce COM parce que j'ai une application qui utilise une classe qui n'est pas listée dans la TypeLib.

Answer 1

Si la bibliothèque de type est vide, il n'y a aucun moyen que vous pouvez trouver des informations sur les types dans une bibliothèque COM.

Vous avez besoin de au moins une entrée de coclasse dans le typelib pour trouver une implémentation de IUnknown.

Si vous avez cela, alors vous pouvez réellement créer des instances de la classe et ensuite appeler QueryInterface sur IUnknown pour l'implémentation IDispatch (s'il en existe une).

Si une interface IDispatch existe, vous pouvez appeler GetTypeInfo pour obtenir des informations sur les interfaces implémentées.

Si vous devez passer des appels en retard à IDispatch, vous devrez appeler le Invoke method. Remarquez, vous mentionnez la bibliothèque de types, mais il est de pratique courante pour les serveurs COM in-process d'incorporer la bibliothèque de types dans la DLL qui est l'implémentation des types représentés dans la bibliothèque. Êtes-vous sûr de ne pas avoir vérifié cela aussi? Ou êtes-vous sûr d'avoir la bibliothèque de types et elle est en effet vide?

Si le type lib est bien vide et la dll ne contient pas, il est tout à fait possible que le dans le sens de type lib était « privé » que d'autres clients ont été compilés contre. COM n'a pas nécessairement besoin d'un type-lib lors de l'exécution. Le modèle pour exposer les implémentations IClassFactory interface consiste à exporter une fonction DLL standard avec une signature bien connue.

On pourrait facilement appeler LoadLibrary, puis appeler le GetProcAddress et distribuer le résultat à IClassFactory. À partir de là, ils utiliseront le GUID privé et l'IID qu'ils connaissent (pas de la bibliothèque de types) ainsi que les interfaces COM qu'ils ont définies en privé et qui fonctionnent à partir de là. Le seul raisonnement que je peux penser pour quelque chose comme ceci est une forme d'obfuscation et/ou adressant des soucis de confidentialité/sécurité, en permettant seulement aux clients le producteur du serveur approuve de l'appeler.

Il ne vous aide pas, mais pourrait expliquer pourquoi vous voyez une bibliothèque de type sans information et en même temps, voir d'autres clients consomment la bibliothèque.

Answer 2

Ne pas utiliser une bibliothèque de type dans la programmation COM est assez commun. N'importe quel langage de script, il utilise IDispatch pour découvrir les méthodes et les propriétés prises en charge lors de l'exécution. IDispatch :: GetIDsOfNames() ou IDispatch :: GetTypeInfo() lance cette opération. C'est ce qu'on appelle la liaison tardive. C'est lent, mais cela n'a pas d'importance dans un langage de script.

Une autre méthode standard est dans les fichiers d'en-tête générés par MIDL à partir d'un fichier .idl qui décrit les interfaces et coclasses. Vous trouverez beaucoup d'entre eux dans le répertoire d'inclusion de Windows SDK, mshtml.h par exemple. Mais cela ne convient qu'au code C/C++ non géré.

Utilisation de COM sans une bibliothèque de type dans un langage managé comme C# est difficile, mais pas impossible. VB.NET est le meilleur langage, il prend en charge la liaison tardive hors de la boîte.C# ira mieux quand la version 4.0 arrivera, elle a un nouveau mot-clé "dynamique".