Library ABI compatibility between versions of Visual Studio

Question

I have two scenarios. Suppose I have 3 shared libraries that export C++ symbols, each built with VS7.1, VS8, and VS9. I compile all 3 in VS9. For some reason, this works. I do not need to recompile the first 2 libraries in VS9 for VS9 linker to successfully find the symbols and link against them.

Now, if I have a library that only exports symbols using C syntax (extern "C"), is this the same? I've heard people say that the ABI for C is standardized, so there is somewhat of a guarantee that you can use a C library compiled in Visual Studio 8 in all versions of Visual Studio.

Basically, the combination of all of these things is confusing. I'm not sure of what guarantees I have between linking against both C++ and C based shared libraries (using their corresponding import libraries) between different versions of Visual Studio. I'd like to hear the general consensus on both forward/backward compatibility of both C AND C++ import or static libraries on any other version of Visual Studio.

The reason this has come up for me is because there are closed-source libraries I'm using that were compiled in Visual Studio .NET 2003 (VS7.1). My team thinks that this locks us to the VS 7.1 compiler, however I've gone out and tested these libraries in both VS8 and VS9, even VS2010 and they link just fine. However, I'm not sure of the inherent danger in this. Note that the library in question has a C variant and a C++ variant. Basically, the C variant is standard-C exports, and the C++ library is an abstraction over the C library and exports classes.

Cesarean

The fact that you can use a binary compiled in a previous version of Visual Studio in a later version is somewhat of a coincidence. This is not guaranteed and you shouldn't rely on it. It really should lock you into an older version of the compiler, unless you can obtain a version of the binary that you can link in dynamically (i.e., a DLL). If you do choose to use a new version of the compiler, extensive testing is completely unavoidable. – Pice

@CodyGray: I agree it's a coincidence, but since those compilers are already released and are the way they are, I have the guarantee that they will work. I think the thing I don't have a guarantee for are future releases of the VS compiler. – Cesarean

Well, that's sort of true. You have a guarantee that everything you test extensively and verify to work will always continue to work. You don't have a guarantee (at least, not provided by the documentation) that any code will work. Hence, the necessity of testing. Agreed though you can probably get away with it for old versions, and right on about future releases being a toss-up. – Pice

Answer 1

The issue may be not only in ABI differences (calling conventions, etc.) between these VS versions, but also in removed/changed symbols in system DLL libraries. See this table for the detailed comparison of system DLL libraries between VS8 (2005, Windows SDK 5.0) and VS9 (2008, Windows SDK 6.0).

See also compatibility matrix for Windows SDKs.

Divorcee

I don't see how Windows SDK changes will matter here, since the closed-source binary built using MSVC 7.1 will always load the MSVC 7.1 runtimes it was built with. – Cesarean

Answer 2

extern "C" exported symbols are different from C++ symbols. C++ has name mangling (see http://en.wikipedia.org/wiki/Name_mangling).

The mangling of C++ symbols may vary from compiler version to compiler version, so in your VS7/8/9 setup, the same C++ method name may be mangled to different names.

Basically, your team seems to be right - you will be locked in the same major version of the compiler that was used to compile your library.

Engler

How is it that I can use a C++ VS7.1 and VS8 library in VS9 then? – Cesarean

According to your wikipedia link, VS6-VS10 share the same name mangling scheme, which would explain why they work. So in fact it IS safe to interchange C++ libraries between those compilers, it seems. – Cesarean

@RobertDailey : Some C++ libraries, but nothing involving the standard library (implementations change between compiler versions which would violate the ODR). It's safest to stick with pure C exports between compiler versions. – Mcgowan