Wrapping a 32-bit COM shell extension in a thin 64-bit DLL

Question

Premise:

I have an old 32-bit COM shell extension (written in C ++). After several years of incompatibility with newer 64-bit systems, we are now updating it to work in a 64-bit Windows environment.

Trick:

The 32-bit COM library contains dependencies on third-party libraries for which there are no 64-bit collections available. Thus, we cannot simply "recompile to 64-bit." Given this limitation, we decided that the creation of a thin 64-bit DLL would be the easiest approach; basically an empty DLL that defines only the necessary interfaces, and redirects all calls to the 32-bit COM library.

I believe that this message between a 64-bit COM-DLL and a 32-bit COM-DLL is possible using COM surrogates. Unfortunately, this seems to be a very specific / niche topic, and I could not find many resources on how to call 32-bit COM-APIs from a 64-bit COM DLL.

Questions:

• Is this "thin COM wrapper" a sensible approach to enable 64-bit functionality of a 32-bit COM DLL?
• Is there a reason this approach will not work specifically for Windows Shell Extensions?
• Are 64-bit definitions identifying interfaces as identical GUIDs as their 32-bit copies?
• Is this a strategy that has been documented in the past?
• Are there any good resources for calling a 32-bit COM-API from a 64-bit COM DLL

Explanations:

This question has a number of aspects that make it unique, setting it apart from the question " Using 32-bit shell extensions in the 64-bit version of Windows 7. "

I am not asking if a 32-bit shell extension can be loaded into a 64-bit explorer process, as the above question does. Rather, I ask if it is possible to create a thin 64-bit DLL implementation that acts as a bridge between the 64-bit explorer process and the 32-bit implementation.

To be clear, this is not possible .

But maybe it ?

Answer 1

Yes, it is possible with DCOM, and your worst problems will be setting permissions for the DCOM component and doing the work of data marshaling.

Is this "thin COM wrapper" a sensible approach to enable 64-bit functionality of a 32-bit COM DLL?

Yes, we did it once when we had to provide an In-proc COM server with 32-bit and 64-bit versions. Basically, we had such a thin server that will be implemented in both 32 and 64 bits (the consumer will download the corresponding one) and redirects calls to the 32-bit outproc server hosted in DCOM.

Is there a reason this approach will not work specifically for Windows Shell Extensions?

You may not be able to set the correct permissions for the outproc server. Most likely it will work. It is impossible to imagine another reason.

Will 64-bit interface definitions use identical GUIDs as their 32-bit copies?

Yes. The COM interface is a contract. You can have as many contract implementations as possible.

Are there any good resources for calling a 32-bit COM-API from a 64-bit COM DLL

Nothing special is required. Just call CoCreateInstance() with CLSCTX_ALL and run it.

Your main concern will be marshaling. You must march data between the client and server, which will now be in different processes. It is best to use marshaling automation (aka typelib marshaling). If it happens that the original interface is not compatible with Automation, try introducing a new interface compatible with Automation, and your shell will then be the server as an adapter. It may be that you may not be able to create a new Automation-compatible interface for your task, but try this because it is your best bet.

Whenever something does not work - something is not marshaled, some dependent files are not found - use Process Monitor to see what happens with the error.

Answer 2

We have a 64-bit application that only successfully uses 32-bit COM applications (such as VB6). This seems complicated, but essentially you just need to add some registry entries for the COM component that you are trying to use, and then you can use it. You can see the details here:

http://www.gfi.com/blog/32bit-object-64bit-environment/ http://www.codeproject.com/Tips/267554/Using-bit-COM-Object-from-bit-Application

So, yes, it will work, but, of course, there is complex complexity, and simple solutions are usually the best.

Alternatively, you can always wrap 32-bit functionality as a service or something like that and access it that way. Or as an executable file and use a text file or something for communication.