Does anyone have any background info on why VB handles Typelib versions in
hex format? I'm developing a specialised in-house version of RegClean but
I'm finding this area to be a complete mess.

Here's what I've deduced so far...

1) The actual Typelib file holds a decimal-format version. Hence TLBINF
always delivers decimal versions in the MajorVersion and MinorVersion
properties
2) Most components register themselves under HKEY_CLASSES_ROOT\Typelib with
a decimal-format Typelib version (e.g. 12.0), whereas VB creates Typelib
entries with a hex format version (e.g. a.0)
3) The VBP project files _always_ specify hex format versions in their
Reference= and Object= lines, even for non-VB libraries. For instance,
CDO.dll (here) has a version of decimal version 1.21 but VBP files reference
it with a version of 1.15 (&H15=21).
4) The HKEY_CLASSES_ROOT\Interface registry entries reference the Typelib
version as stored under HKEY_CLASSES_ROOT\Typelib. For instance, hex-format
if the component is a VB one, and decimal otherwise. This makes matching
them up easy
5) The HKEY_CLASSES_ROOT\CLSID registry entries reference the Typelib
version as decimal. Hence, I need some psychic power to be able to relate
their versions to a HKEY_CLASSES_ROOT\Typelib version unless I know whether
they relate to a VB component or not.

If you know whether a component was built with VB or something else, or you
still have the Typelib file on disk, then all things are possible. However,
a "RegClean" type tool is trying to make sense of orphaned ActixeX registry
entries and I can't see any reliable approach. I did wonder how the public
RegClean.exe copes, but then I'm aware that it doesn't clean up a lot of
stuff that it should. Maybe this issue is the reason.

        Tony Proctor