COM registration of PROGIDs.

We’re almost done with this series (phew). Up until now, everything I’ve talked about w.r.t. COM registration has been required for one scenario or another.  However, there’s one other common aspect of COM registration that is a wonderful convenience (although not necessary except for some relatively rare circumstances).

Of course, I’m talking about the progid.  The PROGID provides the ability to define a string alias for a particular COM object.  Thus with the PROGID, you can access a COM object without having to know it’s CLSID.  This can be quite handy, especially when you’re working in languages that don’t provide easy access to a GUID data type.  A PROGID is simply a string representation of the class. 

By convention the PROGID has the form: <Program>.<Component>.<Version> and should be less than 39 characters in length.  There are a couple of other restrictions spelled out here.

So what are the minimal set of registry keys needed for a progid?

Well, they’re:

    Default Value: Friendly name for ProgID.  Should contain the version number.
    Default Value: CLSID of the object that matches this progid.

There’s an alternate form of the progid, known as the version independent progid, this is simply a progid without the <Version> part of the name.  It has the same format as the version specific progid:

Key: HKEY_CLASSES_ROOT\<Version Independent ProgID>
    Default Value: Friendly name for ProgID.
Key: HKEY_CLASSES_ROOT\<Version Independent ProgID>\CLSID
    Default Value: CLSID of the object that matches this progid.
Key: HKEY_CLASSES_ROOT\<Version Independent ProgID>\CurVer
    Default Value: Version specific PROGID for this COM object.

You don’t have to specify the CurVer key if you don’t have multiple versions, but it’s probably a good idea.

You also need to hook the progid’s back up to the CLSID key for your COM object:

    Default Value: <PROGID> for this COM class.
Key: HKEY_CLASSES_ROOT\CLSID\<Class ID>\VersionIndependentProgIDProgID
    Default Value: <Version Independent PROGID> for this COM class.

Again, PROGID’s are nice-to-have, but in no way are they required.  But they can be quite convenient so…


Comments (4)

  1. Anonymous says:

    Why are all the COM registrations located in the default value of a key and not in a data/value under the UUID? It seems odd to see half a dozen subkeys acting as value entries under any given UUID.

    Is it something that dates back to limitation in the registry used for Win 3.1, or is there a technical reason for it?

  2. That’s a really good question, unfortunately I have no idea 🙁

    My guess is it’s a Win 3.1 thingy but I really don’t know.

  3. Anonymous says:

    In the old days (pre Windows 2000) HKEY_CLASSES_ROOT was simply a SymLink to HKEY_LOCAL_MACHINESoftwareClasses.

    Nowadays HKEY_CLASSES_ROOT is a merged view of HKEY_LOCAL_MACHINESoftwareClasses and HKEY_CURRENT_USERSoftwareClasses and you can never be quite sure what you get when your read or write HKEY_CLASSES_ROOT.

    Therefore you should write your COM registration to either HKEY_LOCAL_MACHINESoftwareClasses or HKEY_CURRENT_USERSoftwareClasses


  4. Anonymous says:

    Is there an API function(s) I can use to return the PROGID for an appication knowing the filename of the application ( e.g. fillintheblank.ocx)?