我知道我可以从Classes\<CLASSNAME>\CLSID\@
从registry中的COM类对象读取CLSID。
我怀疑在一个已注册的COM接口上,我可以从Classes\<CLASSNAME>\IID\@
或Classes\CLSID\<CLSID>\IID
读取Classes\CLSID\<CLSID>\IID
。
我已经阅读了文章的COM ID和registry项,简而言之 ,这个问题仍然对我开放。 不幸的是,我现在还没有testing用例。
注册表并不是一个编程资源,当COM基础设施需要它们时,注册表项才会出现。 例如,CLSID键是帮助COM查找实现服务器的可执行文件所必需的,程序员必须提供CLSID guid。
他还需要知道IID,并将其传递给QueryInterface()以获取接口指针。 在HKLM \ Software \ Classes \ Interface中可能有一个条目,但它并不常见。 当一个接口需要从一个单元到另一个单元进行封送时,COM基础结构需要它,注册表键包含代理的CLSID,以帮助完成这项工作。 使用Regedit.exe快速浏览一下这个密钥应该可以让你确信它不会有什么帮助,它与服务器本身没有任何联系。 只有你非常幸运,你才能在那里找到一个类型库LIBID。
COM程序员有两种基本的方式为您提供CLSID和IID值。 不友好的方式是.idl或.h文件,几个Windows组件(DirectX,Media Foundation,WASAPI等)就是这样。 足以看到IID回来。
友好的方式是一个类型库,一个与所有编译器知道如何读取的实现的同类和接口的语言无关的描述。 有时作为单独的.tlb或.olb文件提供,但通常作为资源嵌入到可执行文件中。 最好的方法是使用Oleview.exe SDK工具。 使用文件>查看Typelib并选择.tlb或.dll文件。 它将类型库反编译回IDL,这是COM作者用来描述他的组件的语言。 您不会找到回IID的麻烦。 只有你必须知道的是可执行文件的名字。
一定要在你的编译器中利用类型库,假设你找到了。 现在,您可以使用友好名称而不是原始GUID,在代码上进行语法检查,并且在版本发生更改并且作者正确使用新IID时,几乎不必做任何有戏剧性的事情。 如果找不到,请务必与作者交谈,一个小小的提示可以为您节省大量的麻烦。