blocks|key|1857290|text|非常简单的解释是，CoGetClassObject()打开HKCR\CLSID\{ClassId}并查看InProcServer32或LocalServer32，这取决于传递的CLSCTX_*值-即COM服务器路径。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1857291|一旦找到COM服务器文件路径就加载到COM服务器(进程内使用LOAD_WITH_ALTERED_SEARCH_PATH标志的LoadLibraryEx()，进程外使用CreateProcess()+)。然后，它定位并调用进程内服务器的DllGetClassObject()，或者等待，直到为进程外服务器注册了类工厂。|1857292|当然，这会忽略DCOM等内容。您可以使用进程监视器工具更好地了解它是如何遍历注册表的。|1857293|entityMap^0|9|I|T|K|1G|E|1V|D|2G|8|0|U|T|1Q|F|2B|F|39|J|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|15|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|K|$]]

The very simple explanation is <code>CoGetClassObject()</code> opens <code>HKCR\CLSID\{ClassId}</code> and looks at <code>InProcServer32</code> or <code>LocalServer32</code> depending on what <code>CLSCTX_*</code> value is passed - that is the COM server path.

Once it find a COM server file path is loads (<code>LoadLibraryEx()</code> with <code>LOAD_WITH_ALTERED_SEARCH_PATH</code> flag in case of in-proc or <code>CreateProcess()</code> in case of out-proc) the COM server. Then it locates and calls <code>DllGetClassObject()</code> for in-proc servers or waits until a class factory is registered for out-proc servers.

This of course ignores stuff like DCOM etc. You can get a better idea of how it traverses the registry using Process Monitor utility.

blocks|key|2229113|text|与CoCreateInstance()相比，CoGetClassObject()只完成一半的工作。它返回一个类工厂。CoCreateInstance()然后调用IClassFactory::CreateInstance()并释放IClassFactory。只有当您需要创建某个coclass的许多对象并希望对其进行优化时，才会使用它。它避免了一次又一次创建和发布工厂的成本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2229114|您可能忽略了这个问题的一个简单得多的解决方案。只需将新版本的COM服务器DLL复制到与客户端EXE相同的目录中即可。并创建一个名为"app.exe.local“的零字节文件，其中"app”是EXE的名称。这足以强制加载复制DLL，而不是注册表所指向的DLL。MSDN+Library关于DLL重定向is+here的文章。|offset|length|2229115|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/aa375142%2528v=VS.85%2529.aspx^0|0|45|7|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

CoGetClassObject() simply does half the job that CoCreateInstance() does. It returns a class factory. CoCreateInstance() then call IClassFactory::CreateInstance() and releases the IClassFactory. You would only use it if you have a need to create many objects of a certain coclass and want to optimize that. It avoids the cost of creating and releasing the factory over and over again.

You are possibly overlooking a far simpler solution to this problem. You can simply copy the new version of the COM server DLL into the same directory as the client EXE. And create a zero byte file with the name "app.exe.local" where "app" is the name of the EXE. That's enough to force that copied DLL to be loaded instead of the one that the registry points to. The MSDN Library article about DLL redirection <a href="http://msdn.microsoft.com/en-us/library/aa375142%28v=VS.85%29.aspx" rel="noreferrer">is here</a>.

blocks|key|1643006|text|如果您希望加载特定的COM，而不管是否安装了较新的版本，也不管较旧的DLL位于何处，则只需完全忽略CoCreateInstance()和CoGetClassObject()。通过LoadLibrary()自己加载旧的动态链接库，然后直接调用其导出的DllGetClassObject()函数来获取动态链接库的IClassFactory接口，然后根据需要调用IClassFactory::CreateInstance()。这是CoCreateInstance()和CoGetClassObject()在内部执行的所有操作，但这绕过了它们执行的注册表查找，以确定要加载的DLL路径。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1643007|entityMap^0|1D|I|1W|I|2H|D|3G|J|4A|D|4Y|V|5W|I|6F|I|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|G|$]]

If you want to load a specific COM DLL regardless of whether there is a newer version installed, and regardless of where the older DLL is located, then simply ignore <code>CoCreateInstance()</code> and <code>CoGetClassObject()</code> altogether. Load the older DLL yourself via <code>LoadLibrary()</code>, then call its exported <code>DllGetClassObject()</code> function directly to get the DLL's <code>IClassFactory</code> interface, then call <code>IClassFactory::CreateInstance()</code> as needed. This is all <code>CoCreateInstance()</code> and <code>CoGetClassObject()</code> do internally anyway, but this bypasses the Registry lookups they perform to determine the DLL path to load.

I have a little problem with <code>CoGetClassObject()</code>.

I have an application which must use some DLLs of a specific version,
but they are also present in the system, in a more recent version.

So I start hooking the <code>CoCreateInstance()</code> and <code>loadLibrary()</code>, which I guess are good.
The problem is that the DLLs in the two versions are loaded.

So I think that <code>CoGetClassObject()</code> is the problem/solution because it provides a pointer to an interface of an object associated with a CLSID containing a DLL that the application must use in an older version.

But I don't know what this function "does", so how can I "override" this function ?

thanks.

PS : I'm new in the COM programming.

COM & CoGetClassObject()

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我对CoGetClassObject()有点小问题。我有一个应用程序，它必须使用一些特定版本的DLL，但它们也存在于系统中，在较新的版本中。所以我开始把CoCreateInstance()和loadLibrary()挂在一起，我想这是很好的。问题是加载了两个版本中的DLL。所以我认为CoGetClassObject()...

问COM & CoGetClassObject()
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问COM & CoGetClassObject()EN