Windows Shell 脚本 (vbs)有以下方法：
object.GetObject(strPathname [,strProgID], [strPrefix])
现在假设我有以下代码：
set myval = getObject("myObjectRef:myObjectArgs")
这适用于一台机器 - 而不是另一台机器。
我想要做的是找到维护所有 myObjectRef/progIds 的最终列表。
我的问题是：GetObject progids 是如何维护的？
假设：
我正在寻找“在注册表中进行搜索”的更复杂的答案
嗯，这有点困难，因为这就是它所需要的。您不必完全“搜索”，只需查看您希望它找到的位置即可。它位于 regedit.exe 中 HKEY_CLASSES_ROOT 配置单元的正下方，这些键按字母顺序排序，因此只需在键盘上键入“m”键，您就已经关闭了您正在寻找的 progid。如果您没有看到“myObjectRef.myObjectArgs”键，那么当 COM 也找不到它时，您可以在运行时依靠 kaboom。
没有“明确的列表”，也没有实体维护 progid 以确保它们是唯一的。该列表特定于每台计算机，该计算机上安装的任何内容都决定了您使用 Regedit.exe 找到的内容。它们只是 GUID 的人性化版本，是定位 COM 组件真正重要的值。明确标识服务器的全局唯一 ID。progid 键的 CLSID 子键提供该 GUID。这是一个很大的数字，对人类不是很友好。
progid 键在组件自行安装时写入注册表。因此，缺少密钥仅意味着未安装它。
在启动 64 位版本的 Windows 的机器上，一个不常见的问题是 COM 服务器只能作为 32 位组件使用，而客户端是 64 位进程。这也在注册表中得到解决，CLSID 键仅存在于 HKLM\Software\Wow6432Node\Classes 中。Wow6432Node 部分是 32 位客户端看到的。因此 64 位客户端在 HKLM\Software\Classes 中查找并找不到密钥。看起来就像一个“未安装”的问题，即使它实际上存在。只是不是它的 64 位版本。SysInternals 的 Process Monitor 是诊断此类问题的绝佳工具。您会看到失败的客户端程序在注册表中搜索。