How to avoid problems with multiple CRT versions on Windows (dll hell revisited?)

Question

I appreciate that similar questions have been asked before - but reading them none of them quite address our issue so thought I'd ask for any insight.

[TL;DR] Version:

Is it possible / easy to create a shim dll for VS2005 CRT which then delegates all calls to VS2013 CRT?

Is it easier to downgrade a VS2013 build so that it uses the VS2005 CRT?

Or are both of these ideas just plain mad?

Our Situation:

Our C++ applications are built using modern versions of C++ compilers (VS2013,gcc 4.8 depending on target platform) - some of our dependencies we use will require a modern version since they use C++11.

Our applications also use run time linking (.dll or .so) to package the various application components.

On windows to make life simple we compile using /MD (or/MDd for debug) ie use the CRT in a dll using multi threaded version - any dependencies we build are recompiled to use the same CRT.

Using the same CRT for all dependencies (in a separate dll) means we avoid problems if memory is allocated in one dll and freed in another since the same heap is used.

Our Problem

We have one dependency which is provided by a 3rd party (I won't name and shame them here - but you know who you are!) as a pre-compiled dll/so rather than as source.

This has been compiled using VS2005 (MSVC8) on Windows and uses the MSVC8 crt.

Their previous version of this dependency worked fine. Their api to this dependency handled allocation and de-allocation of memory correctly so even though it was using a different CRT version to the rest of our application it was not problematic.

Unfortunately their new ("improved"!) version has made heavy use of C++ templates in their api - these templates expand out in our calling code and result in attempts to delete memory allocated within their dll from within our calling code. Since the 2 areas are using different heaps this is very problematic.

Possible Solutions:

To solve this problem we can see the following possible solutions

1]Get the supplier to rewrite (We've asked for this and it is the long term solution but won't happen for some time)

2]Get the supplier to re-compile using VS2013 so we have the same CRT both sides (just plain won't happen apparently - have asked).

3]Use the VS2005 CRT for all our code (We can't simply use VS2005 to build our code since we have a requirement for C++11 support)

4]Shim the VS2005 CRT that 3rd party dll is expecting - ie build something which looks like VS2005 CRT but is actually using the VS2013 CRT.

5]Wrap the 3rd party dll - ie build a dll compiled with VS2005 which contains all the calls to the 3rd party dependency - and provide correct memory handling so that it works with our other (VS2013 CRT using) dlls

And Finally the Question:

Option 5] will probably be the most amount of work (but have the greatest likelihood of success) - its basically option 1] but under our control so we don't have to wait for the 3rd party.

Before committing to this route though I thought I'd ask to see if others have done anything similar to 3] or 4] or some other solution we haven't thought of.

Option 4] (building a shimmed version of CRT) seems possibly the simplest since I imagine lots of the backward compatibility work will be already done in the VS2013 CRT already - so is just a case of finding out the details and fwd'ing the 2005 version of the call to the 2013 version - in many cases I imagine even the signature is identical so is just an implib entry.

However when I looked via google I couldn't find any examples of anyone building shim dlls for CRT version incompatibility problems - so possibly its much harder than I think (or my google fu is severely lacking).

So thought I'd just ask if anyone has done anything similar / knows why its a really silly idea?

Answer 1

There's no reasonable way in which you can achieve that shimming.

The dealbreaker is that the STL implementation has changed, and those are templates. The DLL almost certainly has a mix of inlined and non-inlined calls to the VS2005 STL. If you swap out the VS2005 for the VS2013 CRT, their DLL will have a mix of inlined VS2005 and non-inlined VS2013 calls. A definite disaster. That is assuming the VS2013 CRT even has the non-inlined versions needed.

That said, you can provider your own new and delete in your code. Those can forward to the corresponding VS2005 versions which you retrieve at runtime via GetProcAddress. This could perhaps be sufficient - no guarantees.