3 replies to this topic

[jwezorek]

I'm working on an application that is going to need to use a newer version of a DLL it uses and retain use of the old the version. Currently it implicitly links to the old version of the DLL and to make matters worse ... The DLL exports a class with non-virtual member functions so I don't think I can load it explicitly.

Is it possible somehow to get it to implicitly link to the new version too but under an alias? Meaning having say two versions of the header file and have them each map to seperate versions of the DLL even though the names of the exported class will be the same in the DLLs.

Or can I explicitly load a DLL that exports a class?

Edited by jwezorek, 24 January 2013 - 07:36 PM.

[ApochPiQ]

You can do explicit loading; just have the host app and the DLL agree on the interface you're sharing, and provide a function in the DLL's export table that gets access to an object that implements that interface.

Whether or not that actually works nicely in your situation is debatable :-)

[jwezorek]

The problem is the old version of the DLL exists and is in the wild and it does what it does. I'm working on a new version of one of our applications that has to use the old DLL and a new version of the same DLL and am trying to figure out some way to do this cleanly.

I can't change the old DLL. I maybe can change the new DLL but I'll have to talk to the guy that wrote it, etc., and was hoping there was some way to not touch that code. But I guess it can't be done barring maiking my own wrapper DLL or explicitly linking and doing a weird hack to deal the fact that it is exporting a class.

Edited by jwezorek, 24 January 2013 - 08:07 PM.

[ApochPiQ]

Yeah, if you're limited in making code changes on the DLL side, you're kind of stuck. A shim is probably your best bet.