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.
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.