Étant donné une interface COM Win32, localisez sa bibliothèque de types

Question

Prendre en compte IUniformResourceLocator Interface définie dans intshcut.h.Je sais comment le définir manuellement pour l'interopérabilité COM gérée, mais j'essaie de comprendre si je peux obtenir tlbimp faire ça pour moi.Voici ce que j'ai essayé :

• Effectuez une recherche sur le Web : je ne trouve que le fichier d'en-tête et le CLSID.
• Recherchez le CLSID dans le registre - je ne l'ai trouvé que dans un ShellEx dossier, pas de chemin binaire
• findstr [CLSID] /s *.* du dans les deux system32 et dossiers du SDK Windows

Existe-t-il en fait une définition de bibliothèque de types quelque part (peut-être en tant que ressource de certains dll ou exe) ?Si oui, comment puis-je le retrouver ?

Answer 1

Vous pouvez constater à partir du fichier d’en-tête du SDK intshcut.h qu’il ne sert à rien de rechercher une bibliothèque de types.

La source normale des bibliothèques de types dans le code Microsoft est midl.exe, le compilateur qui traduit les déclarations écrites en IDL, le langage de description d'interface.Cela commence par un fichier .idl, le SDK en contient un certain nombre, mais pas de manière cohérente.Midl génère automatiquement un fichier .h à partir de l'IDL, vous pouvez les reconnaître grâce au commentaire /* ce fichier TOUJOURS GÉNÉRÉ contient les définitions des interfaces */.Ce fichier .h convient au C ou au C++.Et il génère une bibliothèque de types, souvent intégrée en tant que ressource dans une DLL, adaptée à d'autres langages.

Vous pouvez localiser une telle bibliothèque de types en consultant le registre avec Regedit.exe.Le point de départ est la clé HKLM\Software\Classes ypelib, recherchez le guid qui correspond à l'attribut [uuid] sur le library mot-clé dans l'IDL.

Mais les bibliothèques de types ont des limites : elles ont été conçues à l'origine pour bien prendre en charge le sous-ensemble Automation mais ne peuvent pas exprimer toutes les déclarations possibles.La nécessité d'interopérer avec n'importe quel langage peut être très restrictive ou entraîner une surcharge trop importante pour être considérée comme appropriée.Il n’est donc pas rare qu’un programmeur Microsoft crée manuellement un fichier .h.J'utilise toujours le style de programmation COM avec des interfaces dérivées de IUnknown mais n'utilise pas IDL pour les déclarer.Les exemples les plus courants sont les interfaces shell et DirectX.

En résumé, des indices forts indiquent que vous aurez peu d'espoir de trouver une bibliothèque de types :

• Interfaces dérivées de IUnknown au lieu de IDispatch.IDispatch est l'interface de base préférée pour Automation, elle prend en charge la liaison tardive.Le type utilisé par les langages de script
• Un fichier .h qui n'a pas été généré automatiquement par midl.exe, fournissant une forte indication qu'IDL n'a pas été utilisé
• L'absence de fichier .idl.Ce n'est pas une claque totale, Microsoft ne livre parfois que le fichier .h généré à partir de .idl pour des raisons qui ne me sont pas claires.
• La présence de cpp_quote() dans l'IDL.Il s'agit d'une porte dérobée pour injecter des déclarations C++ dans le fichier .h généré, du genre qui ne peut pas être facilement déclaré en IDL.Ce n'est pas une claque, mais un signal fort que vous aurez du mal à consommer la bibliothèque dans un langage autre que C++.
• La présence de fonctions d'usine qui renvoient un type d'interface.Un indice très fort selon lequel les usines de classes COM normales ne sont pas utilisées pour créer une co-classe, du type que vous invoquez avec la fonction CoCreateInstance()
• La présence de typedefs Windows natifs dans le fichier .h, comme HWND et LPCWSTR.Ou des tableaux transmis comme pointeur brut.Ils ne sont pas compatibles avec l'automatisation.

Le fichier d'en-tête intshcut.h touche presque toutes ces puces.Vous devrez créer manuellement les déclarations de l'interface [ComImport].Oui, de petites erreurs très pénibles produisent des erreurs d'exécution très difficiles à diagnostiquer.Gardez à l’esprit qu’il pourrait bien y avoir un autre programmeur quelque part qui a fait ce que vous voulez faire.Avec un peu de chance, Google vous aidera à retrouver son code.Et gardez à l’esprit que vous pouvez toujours recourir au C++/CLI, un langage très performant pour ce type d’interopérabilité car il peut consommer directement le fichier .h.