Loading/interacting with a vb6 COM dll from a 64bit Application

Question

Hi,

I am working on an application that has more than a few dlls written in VB6. VB6 code includes COM dlls and ocx controls. The rest of the code is in C++ and C#. I have been assigned the task to make the application code base compatible with 64bit architectures. Loads of help material is available for C/C++ code so thats not a problem at hand. But it isn't easy to rewrite all of this vb6 code into .net or some other language to make it compatible with 64bit. Neither do I understand all the underlying logic so just assume that rewrite is out of question.

On the other we all know that VB6 dlls wont work in 64bit environment. So what are my options.

1) covert each of the dll into an EXE which will be loaded in 32bit and it can interact with my rest of 64bit application via COM interfaces. Do you foresee any problems with this approach?

2) I edit the registry and load all the VB6 dlls out of process, make them load in dllhost.

3) Make a single 32bit exe, refer all of these VB6 dlls in that exe and load that exe in 32bit address space and the 64bit part of my application communicates with the 32bit exe.

The major problem that comes to my mind with all of the above mentioned approaches is what to do with OCX controls????

Any ideas? If no new ideas than which of the above mentioned will be preferred by you and why?

Answer 1

If you have lots of existing VB6 code that uses to run in-process, I'd first question if migrating to 64 bit is really worth the effort. 64 bit has many advantages for server apps, but for desktop apps, 32 bit is often completely sufficient. And as WOW64 can be expected to be available for at least a decade, there is little speaking against running 32 bit apps on 64 bit Windows.

The point is, although it is possible that by using out-or-process servers you could tweak your app so that it runs at least partially in 64 bit mode, this will probably have a significant impact on performance (and also on memory overhead). Odds are that the customer therefore has absolutely no benefit from choosing the 64-bit version of your app.

That said, I'd say 2) or 3) would be the natural choice. 2) is certainly easier to implement, but 3) gives you more control of how many out-or-process servers should be created and how their lifetime is managed.