CODEWITHSUNDEEP
c++visual-studio-2010visual-studiovisual-studio-2012
hyperknot
hyperknot

Reputation: 13966

Binary C++ library compatibility between VS2010 and VS2012?

I am confused about the binary compatibility of compiled libraries between VS2010 and VS2012. I would like to migrate to VS2012, however many closed-source binary-only SDKs are only out for VS2010, for example SDKs for interfacing hardware devices.

Traditionally, as far as I know Visual Studio was extremely picky about compiler versions, and in VS2010 you could not link to libraries which have been compiled for VS2008.

The reason I'm confused now, is that I'm in the process of migrating to VS2012, and I have tried a few projects, and for my biggest surprise, many of them work cross-versions with no problems.

Note: I'm not talking about the v100 mode, which as far as I know is just a VS2012 GUI over the VS2010 compiling engine.

I'm talking about opening a VS2010 solution in VS2012, click update, and seeing what happens.

When linking to some bigger libraries, like boost, the compiling didn't work, as there are checks for compiler version and they raise an error and abort compilation. Some other libraries just abort at missing functions. This is the behaviour what I was expecting.

On the other hand, many libraries work fine with no errors or additional warnings.

How is it possible? Was VS2012 made in a special way to keep binary compatibility with VS2010 libraries? Does it depend on dynamic vs. static linking?

And the most important question: even though there is no error raised at compile time, can I trust the compiler that there won't be any bugs when linking a VS2012 project to VS2010 compiled libraries?

Upvotes: 4

Views: 3739

Answers (1)

JDługosz
JDługosz

Reputation: 5642

“Many libraries work fine. How is it possible?”

1) the lib is compiled to use static RTL, so the code won't pull in a second RTL DLL that clashes.

2) the code only calls functions (and uses structures, etc.) that is completely in the header files so doesn't cause a linker error, or calls functions that are still present in the new RTL so doesn't cause a linker error,

3) doesn't call anything with structures that have changed layout or meaning so it doesn't crash.

#3 is the one to worry about. You can use imports to see what it uses and make a complete list, but there is no documentation or guarantee as to which ones are compatible. Just because it seems to run doesn't mean it doesn't have a latent bug.

There is also the possibility of

4) the driver SDK or other code that's fairly low level was written to avoid using standard library calls completely.

also (not your situation I think) DLLs can be isolated and have their own RTL and not pass stuff back and forth (like memory allocation and freeing) between different regimes. In-proc COM servers work this way. DLLs can do this in general if you're careful about what you pass and return and what you do with things like pointers. Crypto++ for example is initialized with the memory routines from the enclosing program and doesn't expose malloc'ed memory from the RTL version it was compiled with.

Upvotes: 3

Related Questions