com surrogate related question
Hi guys,
I am in the situation of having a 32bit dynamic COM library + headers which I can not rebuild but which I would like to use from within a 64bit application.
After some reading and testing I figured out that it should be possible to write a 64bit stub/proxy to access the DLL's functionality but so far I just partially succeeded.
Here is what I did so far.
a) Registered the (actually two) COM DLLs through regsvr32
b) Created a new (and empty) 'Application' Foo under 'Component Services' -> 'My Computer' -> 'COM+ Applications'
c) Added the previously registered 32bit components under 'COM+ Applications' -> 'Foo' -> 'Components'
After this, I created an empty console application (64bit configuration) and within the main function I tried to create instances of the registered components through
CoCreateInstance(clsid, NULL, CLSCTX_LOCAL_SERVER | CLSCTX_ACTIVATE_32_BIT_SERVER)
which is working -- so far so good. Calling functions of the components works too, but not in all cases and this is my actual problem.
When I omit steps b) and c) from above, compile my test program for 32bit and instantiate components with CLSCTX_ALL everything works fine but as soon as I use the surrogate, the same test program fails - even in pure 32bit mode (i.e. calling a 32bit surrogate from a 32bit app).
The error I am receiving is "COM Surrogate has stopped working", and the function call's error handle says "The remote procedure call failed.". As suggested somewhere on the net, adding the 32bit COM surrogate (dllhost.exe) to the DEP exception list did not solve the issue.
I am absolutely not a Windows nor COM specialist and I assume and hope that I am doing something wrong and that there is a way to fix my problem. Any advice is appreciated.
Thanks in advance,
- Hauke
Re: com surrogate related question
You cannot natively use a 32bit in process COm server from a 64 bit application (or vice versa).
Your best shot is making 32bit host application that interfaces to your 64bit application.
You can either do this by making a 32bit out of process COM wrapper. Having the functions you need. Or you could use the DCOM approach although that may take some time to investigate how to get it working.
Both methods sort of assume the COM won't be having any kind of visual UI in your application. If it is a COM component havign a visual UI, then chances are you won't get it working with a satisfying result.
Contact the vendor of the COM component and requesting a 64bit version is then your best bet.
You claim it doesn't even work when called from a 32bit process... Then it is possible the component has a bug, or doesn't work well on your version of Windows. Again, this is something you should take up with the vendor of the component.
1 Attachment(s)
Re: com surrogate related question
First, thank you for answering.
Quote:
Originally Posted by
OReubens
You can either do this by making a 32bit out of process COM wrapper. Having the functions you need. Or you could use the DCOM approach although that may take some time to investigate how to get it working.
I was under the impression that the creation of a "COM+ Application" as I did it (in particular steps b and c) was something like creating an OOP COM wrapper. Under properties (see attachment), on the 'Activation' tab I selected 'Server application' and there is an explicit note that the components will be activated in a dedicated server process. When I do create an instance of a class like this
Code:
HRESULT hr;
CComQIPtr<IBar> bar;
hr = bar.CoCreateInstance(CLSID_IBar, NULL, CLSCTX_LOCAL_SERVER | CLSCTX_ACTIVATE_32_BIT_SERVER);
I do see the 32bit "COM Surrogate" being started in the "Process Explorer" as well as the 32bit COM DLLs of the library I want to work with being loaded - as expected as part of the "COM Surrogate's" process. Maybe I misconfigured the COM+ application in some way.
Also, since I forgot to mention that beforehand, I am running a 64bit Windows 7 Professional (Build 7600).
Quote:
Originally Posted by
OReubens
... won't be having any kind of visual UI in your application.
Fortunately no UI stuff involved. I am dealing with data loading functionality and currently there is no hope for a 64bit version.
Quote:
Originally Posted by
OReubens
You claim it doesn't even work when called from a 32bit process... Then it is possible the component has a bug, or doesn't work well on your version of Windows. Again, this is something you should take up with the vendor of the component.
I am not sure about this, since when omitting the COM+ App creation and simply registering the COM DLLs and when using
Code:
HRESULT hr;
CComQIPtr<IBar> bar;
CComQIPtr<IFoo> foo;
hr = bar.CoCreateInstance(CLSID_IBar, NULL, CLSCTX_ALL);
hr = foo.CoCreateInstance(CLSID_IFoo, NULL, CLSCTX_ALL);
hr = bar.dodgyMethod(foo); // this is the trouble maker
everything works just fine. It's just that using the DLL through a surrogate does neither work in 32 nor 64 bit.
Anyways, maybe I am on the wrong track and need to get myself a book on COM before continuing.
Regards,
- Hauke
