COM surrogate for a third-party component

Question

I am writing a small DLL component that must have access to two third-party components to combine data, one of which has only 32 bits and the other only 64 bits. Both are registered with TypeLib and are compatible with Automation, so sorting should not be a problem.

If I understand the documentation correctly, then there is no way to force download to the surrogate, if the component also does not have the AppID and DllSurrogate keys; since both are third-party components, I am somewhat reluctant to change 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 additional dependencies, or can someone explain to me why this would be a bad idea?

Answer 1

Yes, you can download (for example) a 32-bit DLL only in a surrogate and access it from a 64-bit process as follows. This will work if there is an available marshaller, which will usually be for a component with typelib, because they usually use a standard marshaller. This will not work if the object requests a custom proxy / stub because 64-bit versions will not exist or you will not have this problem in the first place.

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

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

You must use the 32-bit version of Regedit for this, since it is a 32-bit component. If you have a 64-bit component that you want to access from 32-bit, use another. (This is due to registry virtualization for the 32-bit compatibility level - using the appropriate version of bitty regedit will take care of this problem, making sure that you are editing the correct virtualized 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 the file myComponent-dllhost.reg and you will be gone.

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

You can now access Capicom.HashedData and Capicom.EncryptedData from 64-bit script / COM hosts.

Notes:

• This only works for basic types of OLE automation. Any object compatible with Windows Scripting scripts in VBScript or JavaScript should be in order.
• You need to add the AppID only to the created objects. These are mainly those that have an InprocServer32 entry. Objects created at the factory or accessible only as child objects must not contain an AppID.
• If you already have an AppID, you need to add an entry with the empty string "DllSurrogate". What is it!
• this will NOT affect regular DLL clients. As long as the bitness matches, they will still be loaded in the process, as before. The only difference that this will make is that it will become possible to create an instance of it outside the process from the client with varying degrees of detail.