We have a situation where one of our products is a 32-bit app, but needs to communicate with instruments via 64-bit COM control (which wraps a 64-bit device driver). For various reasons, we don't want to compile this app as a 64-bit app, but we DO want to run it on a 64-bit OS. Since the drivers and COM control must be 64-bit to work, what are our options for accessing them from the 32-bit side?
Can anyone point me in the right direction on this?
Thanks
Curtis
I don't think there is a simple solution. A 32-bit application cannot make calls into a 64-bit DLL (or vice versa). One solution often mentioned is to use some kind of IPC (interprocess communication) to make calls on behalf of the application into the DLL. It would be a kind of IPC thunking layer.
In your case, you would need a "small" 64-bit application to actually make calls into the 64-bit COM control object and communicate the results back to the 32-bit application. It would probably not be a simple solution.
May work fairly directly, as long as the COM interface only uses types which can be automatically marshaled by the COM subsystem (eg: automation compatible).
You will need to make sure the other COM object is running in it's own process space; if it's not designed to do so, putting it inside a [server type] COM+ application should suffice.
If the interface parameters cannot be automatically marshaled, or the COM object cannot run out-of-process for whatever reason, you will need an interstitial module (which can be another COM object) which meets those requirements. However, it's much easier to make this scenario work than a simple DLL, so you're ahead of the game.