Binary C ++ library compatibility between VS2010 and VS2012?

Question

I am confused about the binary compatibility of compiled libraries between VS2010 and VS2012. I would like to upgrade to VS2012, however, many closed-source binary SDKs are only available for VS2010, such as an SDK for interfacing hardware devices.

Traditionally, as far as I know, Visual Studio was very selective about the versions of the compiler, and in VS2010 you could not refer to the libraries that were compiled for VS2008.

The reason I'm confused right now is because I am switching to VS2012 and I have tried several projects, and to my great surprise, many of them work without cross versions.

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

I am talking about opening a VS2010 solution in VS2012, clicking on an update, and see what happens.

When linking to some larger libraries, for example boost, compilation does not work, because there are checks for the compiler version, and they create an error and interrupt compilation. Some other libraries simply break with missing functions. This is the behavior I was expecting.

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

How is this possible? Has VS2012 specifically supported binary compatibility with VS2010 libraries? Does it depend on dynamic or static binding?

And the most important question: despite the fact that no error occurs during compilation, can I trust the compiler that there will be no errors when linking the VS2012 project with the compiled VS2010 libraries?

Answer 1

"Many libraries work fine. How is this possible?"

1) lib is compiled to use static RTL, so the code will not drag the DLL that it encounters into the second DLL.

2) the code calls functions (and uses structures, etc.), which is completely in the header files, therefore does not cause a linker error or calls functions that are still present in the new RTL, therefore, does not cause a linker error,

3) does not cause anything with structures that have changed the layout or value so that it does not work.

# 3 is the one to worry about. You can use the import to see what it uses and make a complete list, but there is no documentation or guarantee which of them are compatible. Just because it seems to work does not mean that it does not have a hidden error.

There is also the possibility

4) Driver SDK or other code that was written at a fairly low level so as not to use standard library calls completely.

also (not your situation, I think) DLLs can be isolated and have their own RTL, and not transfer material back and forth (for example, memory allocation and freeing) between different modes. B-COM servers work this way. DLLs can do this at all if you are careful about what you are going through and returning to, and what you are doing with things like pointers. For example, Crypto ++ is initialized with memory routines from the supplied program and does not expose malloc'ed memory from the RTL version with which it was compiled.