Loading / interacting with dll vb6 COM from a 64-bit application
I am working on an application that has more than a few DLLs written in VB6. VB6 code includes COM libraries dll and ocx. The rest of the code is in C ++ and C #. I was assigned the task of making the application code base compatible with 64-bit architectures. Loads of reference material are available for C / C ++ code, so this is not a problem. But rewriting all this vb6 code to .net or some other language isn't easy to make it 64bit compatible. I also don't understand all the underlying logic, so just assume rewriting is out of the question.
On the other hand, we all know that the VB6 DLL will not work in a 64-bit environment. So what are my options.
1) hides each of the dlls in the EXE, which will be loaded in 32 bit and can interact with my rest of the 64 bit application via COM interfaces. Do you foresee any problems with this approach?
2) I edit the registry and load all the VB6 dlls from the process, forcing them to be loaded into dllhost.
3) Make one 32-bit exe, link all these VB6 dlls to this exe, and load the EXE into a 32-bit address space, and the 64-bit part of my application links to the 32-bit exe.
The main problem that comes to my mind with all of the above approaches is what to do with the OCX controls?
Any ideas? If you don't need new ideas other than the ones you mentioned above, and why?
a source to share
If you have a lot of existing VB6 code that is used to run in a process, I would first ask if it is really worth going to 64-bit. The 64-bit version has many advantages for server applications, but for desktop applications, 32-bit is often sufficient. And as expected, WOW64 will be available for at least a decade, says little against running 32-bit applications on 64-bit Windows.
The point is, while it is possible that with external servers you can configure your application to run at least partially in 64-bit mode, this is likely to have a significant performance impact (as well as memory overhead). The odds are that the client has absolutely no benefit from choosing the 64-bit version of your application.
So I would say 2) or 3) would be a natural choice. 2) is certainly easier to implement, but 3) gives you more control over how many external servers should be created and how their lives are managed.
a source to share
I am migrating from SQL 2000 x86 to SQL 2008 x64.
We are facing a similar problem here. I decided to use DCOM.
How it works?
32-bit servers will host the assembly and 64-bit machine is called using DCOM.
There is an execution penalty. BTW, the effort versus rewriting ... certainly worth doing. :)
Regards, Marcos Lima
a source to share