Question

I’m writing a small DLL component that needs to access two third party components to combine data, one of which is 32 bit only and the other is 64 bit only. Both are registered with a TypeLib and are Automation compatible, so marshalling should not be an issue.

If I understood the documentation correctly, then there is no way to force loading in a surrogate unless the component also has an AppID and the DllSurrogate key; since both are third party components, I’m somewhat reluctant to modify their registration.

Is there a way to activate an object in a component without an AppID in a surrogate process from a DLL component that ideally does not have any extra dependencies, or can anyone explain to me why this would be a bad idea?

Answer 1

Yes, you can load a (for example) 32-bit only DLL in a surrogate, and access it from a 64-bit process, in the following manner. This will work provided there is a marshaller available, which there generally will be for a component with a typelib because they usually use the standard marshaller. It will not work if the object requries a custom prox/stub because 64 bit versions won’t exist, or you wouldn’t have this problem in the first place.

First you need an AppID. If the DLL already has an AppID, you should use that. You can find out by checking under the CLSID key for the CoClass you are interested in.

The example used here is the Capicom.HashedData and Capicom.EncryptedData classes. Capicom is 32-bit only.

You should use the 32-bit version of Regedit to do this, as it is a 32-bit component. If you have a 64-bit component you want to access from 32-bits, use the other one. (This is because of the registry virtualisation for the 32-bit compatibility layer- using the the matching bitness version of regedit takes care of this issue for you, by making sure you edit the correct virtualised version of the registry).

Windows Registry Editor Version 5.00


;;; Capicom AppID - just using the Capicom.EncryptedData CLSID
;;; Use default surrogate = empty string
[HKEY_CLASSES_ROOT\AppID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}]
"DllSurrogate"=""

;;; Capicom.EncryptedData
[HKEY_CLASSES_ROOT\CLSID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}]
AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}"

;;; Capicom.HashedData - use same AppID for all!!!!!
[HKEY_CLASSES_ROOT\CLSID\{CE32ABF6-475D-41F6-BF82-D27F03E3D38B}]
AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}"

Save to a myComponent-dllhost.reg file, and away you go.

c:\windows\sysWow64\regedit.exe "myComponent-dllhost.reg"

You should now be able to access Capicom.HashedData and Capicom.EncryptedData from 64-bit script/COM hosts.

Notes:

• This only works for basic OLE Automation types. Any object compatible with Windows Scripting Host scripts in VBScript or JavaScript should be OK.
• You only have to add the AppID to directly creatable objects. That’s basically those with an InprocServer32 entry. Objects which are generated from factories or which are only available as child objects do not have to have an AppID added.
• If there is already an AppID all you need to do is add the empty-string “DllSurrogate” entry. That’s it!
• this will NOT affect normal clients of the DLL. As long as the bit-ness matches, they will continue to be loaded in-process as before. The only difference it will make is that it will become possible to instantiate it out-of-process from a client of a different bitness.