Loading multiple instances of a DLL?

[CJ1]

Here is one that I am having trouble with.

I need to load multiple instances of a DLL in my application and have each instance isolated from the others (the DLL has global variables).

In the past we had multiple applications running and each application loaded the DLL. Because the application was in a differn process, each application got its own copy of the global variables.

I need to merge all the old applications into one, but I can't figure out how to isolate the DLL (changing the DLL is NOT an option).

The solution can be C++, MC++, C#, .NET whatever, this part is starting from a clean page. I looked at .NET remoting, but for a singleton invocation the DLL is shared with all clients.

Anyone with any ideas?

[OReubens]

It is not possible to load a single DLL multiple times into an exe's process space.

You can try making physical copies of the DLL, and using loadlibrary/getprocaddress on the new filenames, but it is highly dependent on how the DLL is written if this is at all going to work.

Using importlibraries is not going to work anyway because of name collisions, loadlibrary/getprocaddress for loading the same DLL multiple times (provided they are different physical files) may work, but no guarantees on that.

[VladimirF]

I am not saying that this is a good way, but when we converted some lagacy application few years ago, I did what OReubens suggested: cloned that dll, and used different copies for different clients. You can even do it at run time, "on demand".

[OReubens]

I am not saying that this is a good way

Quite the contrary, I would say it is most definately a BAD idea. However sometimes it's a necessity. I had to use this technique a couple years ago when changing a legacy app, and new features had to be made available quickly.

Eventually the entire DLL was rewritten to support multithreading/clients natively.

[VladimirF]

Was it also (like the one I was working with) written in Fortran?

[OReubens]

No, it was (very poor) C.

Once we duplicated the functionality of the DLL, not only did we have a more stable product. It was also 10x (times, not percent) faster on just a single thread. Multithreading, better I/O handling and multi CPU support made it another order of magnitide faster.

Don't always asume that whoever is making the libraries you're using is making a good job of it ;-)

[CJ1]

I thought that under DCOM you could isolate the DLLs?

I could always go back to launching the DLLs in seperate apps and using shared memory or named pipes to communicate, but I really wanted to avoid that.

What about .NET? Can I isolate the DLL in a .NET app?