views:

204

answers:

1

I have a 32-bit native C++ ATL in-proc COM server which depends on a huge set of legacy 32-bit libraries. I need to use it from a 64-bit application with the smallest changes possible.

One option is putting it into a COM+ application. What are other easy options?

A: 

Create a 32bit helper application that loads the inproc server dll, but that acts as a local server.

Compile the proxy stub code for 64 bits.

Then, when a 64bit app tries to load your ActiveX, instead of using a 32bit inproc (which it cannot load) it will load the 32bit local server - a separate process - which is legal.

The proxy stub which is auto generated code from your IDL should build for 64bits just fine.

Chris Becke
This sound like a lot of work. I'll need to create a separate .exe, figure out how to register it and the proxy/stub in the registry.
sharptooth
Thats all standard stuff though.The alternative is refactoring your COM dll to build - and work - in 64bits.You simply cannot load a 32bit dll into a 64bit process, so figuring out how to host it in a 32bit process is really the only way to avoid rebuilding the control as a 64bit control.
Chris Becke
Yes, I understand that. Just the solution you propose sounds like a lot of work compared to just putting into COM+ - and that's just several clicks with the mouse.
sharptooth
if there isn't a *need* for 64 bit, the easy way is one you've already nixed. Compile the new app as 32 bit until you've converted the 32 bit code into 64bit. . . It's always a pain to make these conversions... I helped out on a 16 bit (pre ANSI) c to 32 bit c/c++ conversion about a decade ago... it was a long project.
Jason D

related questions