How are the GetObject progids maintained?

Question

Windows Shell Scripting (vbs) has the following method:

object.GetObject(strPathname [,strProgID], [strPrefix]) 

Now suppose I have the following code:

set myval = getObject("myObjectRef:myObjectArgs")

This works on one machine - and not on another.

What I want to do is find the definitive list where all the myObjectRef/progIds are maintained.

My question is:How are the GetObject progids maintained?

Assumptions:

• I'm looking for an answer more sophisticated that "do a search in the registry"
• I'm looking to find a particular place where I can go looking for my progid to see if it exists or not.

Answer 1

I'm looking for an answer more sophisticated that "do a search in the registry"

Well, that's a bit difficult because that is really all it takes. You don't exactly have to "search", just look at where you expect it to find. Which is right underneath the HKEY_CLASSES_ROOT hive in regedit.exe, the keys are sorted alphabetically so just type the "m" key on your keyboard and you are already close the progid you are looking for. If you don't see the "myObjectRef.myObjectArgs" key then you can count on a kaboom at runtime when COM cannot find it either.

There is no "definite list" and no entity that maintains progids to ensure that they are unique. The list is specific to each machine, whatever was installed on that machine determines what you find back with Regedit.exe. They are simply a human-friendly version of the GUID, the value that really matters to locate a COM component. A Globally Unique ID that unambiguously identifies the server. The CLSID subkey of the progid key provides that GUID. It is a big number, not very human-friendly.

The progid key is written to the registry when the component installs itself. So a missing key simply means that it isn't installed.

A not uncommon problem on machines that boot a 64-bit version of Windows is that the COM server is only available as a 32-bit component but the client is a 64-bit process. This is resolved in the registry as well, the CLSID key is only present in HKLM\Software\Wow6432Node\Classes. The Wow6432Node section is what a 32-bit client sees. So a 64-bit client looks in HKLM\Software\Classes and won't find the key. Looks just like a "not-installed" problem, even though it is actually present. Just not the 64-bit version of it. SysInternals' Process Monitor is a great tool to diagnose problems like this. You see the failing client program searching through the registry.