I have a closed executable (with no source) which was compiled with VC++ 7.1 (VS2003).
This executable loads a DLL for which I do have the source code.
I’m trying to avoid compiling this DLL with the VS2003 toolkit, because it involves installing this toolkit on every machine I want to compile it on, and to use a makefile instead of directly use the newer VS project.
I changed parameters like the runtime library (I use /MT instead of /MD to prevent runtime DLL conflicts) and some other language switches to maintain compatibility with the old compiler. Finally it compiled and linked fine with the VS2005 libs.
But then when I tried running it, it crashed. The reason: The DLL sends an std::string (and on other places – an std::vector) back to the exe, and the conflicting STL implementation versions cause something bad to happen.
So my question is: Is there a way to work around it? Or should I continue compiling the DLL with the VC7.1 toolkit?
I’m not very optimistic, but maybe someone will have a good idea regarding this.
Thanks.
As the implentations of the stl libraries change, that breaks binary compatability, which is (to my understanding) when the size/member variables of an object changes. The two sides don’t agree on how big a std::string/vector/etc is.
If the old executable thinks a std::string is 32bit char* ptr, and 32bit size_t length, and the new executable thinks a std::string is a 64bit iterator* iterator_list, 64bit char* ptr, 64bit size_t length, then they can’t pass strings back and forth. This is why long-standing formats (windows, bmp) have the first member is a 32bit size_of_object.
Long story short, you need the older VS2003 version of the library (I don’t think you necessarily need the compiler)