Was ist der Unterschied zwischen dem Aufruf von CComModule.RegisterServer, _AtlComModule.RegisterServer und LoadTypeLibEx für die TypLib-Registrierung?

Question

In meiner DllRegisterServer-Methode meiner COM-DLL hatte ich zuvor Code, der LoadTypeLibEx (Modul, REGKIND_REGISTER, & pTypeLib) angerufen, um meine COM-Klassen und ihre entsprechenden TypLibs zu registrieren. Meine COM-DLL ist ein 64-Bit. Ich habe bemerkt, dass auf meinem 64-Bit-Vista-System, unter HKCR: \\ TypeLib \ {myguid} \ 1.0 \ 0 Ich finde einen Win32-Unterschlüssel mit dem Speicherort meiner COM-DLL.

Ich habe auch einige andere Code in einer separaten COM DLL, die ich unterstütze, die den älteren, jetzt veralteten CComModule.RegisterServer (TRUE) Aufruf verwendet. Dieser Code erstellt einen Win64-Unterschlüssel unter der 0-Taste für eine 64-Bit-DLL und einen Win32-Unterschlüssel unter der 0-Taste für eine 32-Bit-DLL. Ich benutze die korrekte Bit-Version von Regsvr32, um die Registrierung in allen Fällen durchzuführen (die Regsvr32-Bitness mit DLL-Bitness übereinstimmen).

Warum erstellen LoadTypeLibEx und _AtlComModule.RegisterServer nicht den Schlüssel win64 für eine 64-Bit-DLL, die meine TypeLib enthält, während der ältere CComModule.RegisterServer die richtigen Schlüssel erstellt?

Answer 1

Es scheint, dass das Verhalten, das ich über win32/win64-Unterschlüssel sehe, die Tatsache widerspiegelt, dass einige Typbibliotheken in 64-Bit- und 32-Bit-Programmen verwendet werden können, da sie keine Bitbeschränkung enthalten (read: pointer)) Parameter. Andere Typbibliotheken benötigen unterdessen andere Einträge für win32 und win64, da sie nicht kompatibel sind.

So scheint es, dass das Verhalten, das ich sehe, nicht wirklich wegen der Registrierungsmethoden ist, die ich verwende, aber wegen der zugrundeliegenden Typenbibliotheken.