I would like to know, is calling code placed in a .dll, which was build with a different tool-chain, possible? And is using a .lib file build with an older compiler to build a code with a newer one possible?
I know, the second one is not preferable, but I would like to know, is it impossible.
Precisely my case looks like this:
I have a.exe
file built with VC7.1 using b.lib
file which was also built with VC7.1 . a.exe
calls code from c.dll
which was built also using b.dll
. Now I want to write a new c.dll
, but compile it with VC9. (I want to do so, as I need some libraries which do not provide support for building them with VC7.1 .) -- My c.dll
also requires b.lib
, still I have sources for it, thus I can recompile it.
So, is it possible to make it work? If not, can you provide a brief explanations, what exactly disallows this?
It is not entirely impossible. The chief problem is that you'll inevitably end up with two distinct copies of the runtime library. Copies that each keep their own state and use their own memory allocator. The DLL interface has to be carefully designed to avoid the possible mishaps that can cause.
Hard rules are that you can never throw an exception from the code in the DLL and catch it in the EXE. And that you cannot return a standard C++ library object like std::string from your DLL code, they have different implementations and the EXE cannot properly destroy the object since it uses a different allocator. And the more general rule, the DLL can never return a pointer to an object that needs to be released by the caller. CRT state can cause subtle problems, like errno not returning the proper error code and locale being set wrong. All and all, plenty of misery that's very hard to diagnose and even harder to fix.
The COM programming model is an example of one that's safe. It never exposes implementation, only pure abstract interfaces. No exceptions, only error codes. Objects are allocated by a factory and reference counted. And where absolutely necessary, it uses a common heap to allocate from, CoTaskMemAlloc(). Not a popular programming model but that's what it takes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With