Where exactly are CLSID entries supposed to go in the registry for VB6 to find them?

[Ben321]

I'm trying to manually register the a class in an experimental ActiveX DLL I made using assembly language. The DLL has no DllRegisterServer function (as I have no idea how one would go about coding a DLL that can register itself) so I will need to manually add the registry entries. I already made a TypeLib for the classes and interfaces in the DLL and registered that by loading the TLB file with VB6, so it knows all the correct GUIDs. But the New keyword in VB6 isn't working for making an instance of the class, because VB6 isn't able to find the DLL. This is because it needs to be able to find the DLL file itself (something the TypeLib doesn't tell it), as this would be in the registry CLSID entry. A key for a specific class's GUID appears alongside many others, all within a key called CLSID. The structure of each such class GUID entry looks something like this:

Key {GUID}
    Value (Default) = CLASS_NAME
    Key InProcServer32
        Value (Default) = PATH_TO_DLL
        Value ThreadingModel = Apartement

But the problem is where is the GUID key for a 32bit ActiveX DLL supposed to go? It must be in one of the several keys called CLSID. However, there's potentially up to 3 possible places on 32bit Windows, and up to 4 places on 64bit Windows, that a 32bit ActiveX DLL could be registered. These are as follows.

32bit class entries on 32bit Windows (and 64bit class entries on 64bit Windows)
HKEY_CLASSES_ROOT\CLSID
HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID

32bit class entries on 64bit Windows
HKEY_CLASSES_ROOT\WOW6432Node\CLSID
HKEY_CURRENT_USER\SOFTWARE\Classes\WOW6432Node\CLSID
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID

Now the problem with these, is I don't know which of these are true keys, and which are effectively shortcuts to keys. I've heard that all the keys in HKEY_CLASSES_ROOT are just shortcuts (not true keys). But what about some of the others? The most glaring example are these two very similar looking keys:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID

Which of those is the true key, and which is the shortcut? Or are they both true keys?

[fafalone]

https://learn.microsoft.com/en-us/wi...-registry-keys

Look at existing VB6 components for the best examples. You'll always want to use HKLM instead of HKCU so VB6 sees it. Generally need to run as admin to register there. As I understand it you'd not worry about WOW6432Node keys yourself; the registry handles that on the back end by virtue of the calling application being 32bit on a 64bit OS.

DllRegisterServer/DllUnregisterServer are just standard DLL exports that write all the keys with your normal registry APIs, there's nothing special about it. regsvr32 calls these functions in your DLL. If you've gone as far as you have might as well do this properly too.

[wqweto]

Or are they both true keys?

Most of these are symbolic links to the right location in the registry. Your app actually doesn't care and just writes to HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID or HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID and leave to the OS to figure out where to store the key/values.

VB6 produced Ax DLLs (and EXEs) always write to HKEY_LOCAL_MACHINE. VB6 does not read registry keys directly but uses standard COM functions so CreateObject can instantiate Ax servers both from HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER.

If you are going to implement DllRegisterServer entry point of your custom Ax DLL but a good netizen and register your COM server in HKEY_LOCAL_MACHINE if current OS user is administrator or register in HKEY_CURRENT_USER if they are non-admin. This way your Ax DLL will work in VB6 just fine even if the developer/user doesn't have admin rights.

cheers,
</wqw>