vs2012 toolset compatibility

Question

In my VS2012 I have 4 toolsets available: v90, v100, v110 and v110_xp. I did a simple test with two projects testlib (a static library) and testexe (console application). The interface was just one function with signature void test(). The results:

• testlib(v90), testexe(anything other than v90) -> does not link
• testlib(v100), testexe(v110 or v110_xp) -> does link

However, it seemed somewhat weird to me that v100 and v110 would link so I tried to complicate the scenario a little bit. Now my method looks like this: std::map<std::string, std::string> test(const std::string& arg). As expected, the testlib(v100) and testexe(v110) do not link (mismatch detected for '_MSC_VER').

But still the testlib(v110) and testexe(v110_xp) do link and the resulting exe works on Windows XP. Is this just by chance or is this a supported scenario? If this is just by chance then an example code that is using only features available in v110_xp and breaks this compatibility would be welcome. I am wondering whether I should deploy two versions of my library to my clients or just the one compiled with v110 will do.

Answer 1

Mixing v110_xp executables and v110 libraries is officially unsupported.

Having escalated this issue separately with Microsoft they responded to these questions:

Q1: Can the application which uses these libraries (v110) and is built with toolset v110_xp run properly on Windows XP machine?

Only executable built with v110_xp toolset can run properly on Windows XP machine. As a result, if the application need to run properly on Windows XP machine, you will need to make sure that your project is switched from the default v110 toolset to the newly introduced v110_xp toolset inside your project’s property pages, including the executable and DLLs if there is any.

Q2: Do we need to release another version of these libraries built with toolset v110_xp?

I think this depends on what kinds of platform do you need to deploy your application on. If your deployment plan includes Windows XP machines, it is necessary to release a new version of the executable/DLLs built with v110_xp toolset. However, considering that the same executable/DLLs built with v110_xp toolset will also run on Vista and later, I suggest that you can just keep a single version of the executable/DLLs built with v110_xp toolset and this can run on all of other platforms. When Windows XP is no longer in your deployment plan, then you can convert the whole executable/DLLs to be rebuilt with v110 toolset. Certainly it will be good if you can maintain the two versions of executable/DLLs in the same time if you want to target Windows XP and other system separately.

Q3: Does Microsoft support libraries built with toolset v110 on Windows XP?

The answer is NO. Everything needs to be built in v110_xp mode if you want to run the application properly on Windows XP.

Answer 2

The word "toolset" is a bit of a misnomer to describe the differences between v110 and v110_xp. You are still using the same build tools. And you still have the same version of the CRT. Something you can see by comparing what you see in the Debug + Windows + Module list of loaded DLL between the two builds. Note the name and location of msvcr110.dll.

The CRT was in fact updated by Update 1, it now supports both XP and newer Windows versions. This works by it binding dynamically to the later winapi functions at runtime, using GetProcAddress(), limping along if it can't find them when you run on XP.

What is different is that you got another version of the Windows SDK. The last one that was still compatible with XP, version 7.1. You'll find it back in C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A. When you build with the v110 toolset then you'll use the SDK include and library files stored in C:\Program Files (x86)\Windows Kits\8.0

The specific changes when you use v110_xp are visible when you search the c:\program files (x86)\msbuild directory for that string:

• the directories for include and lib files, etcetera, are changed to the Windows 7.1 SDK paths
• the _USING_V110_SDK71_ preprocessor symbol is added, not otherwise used anywhere important
• the linker's /SUBSYSTEM option is altered to require only Windows version 5.02, the XP version number.

Long story short, mixing modules that were built with a mix of v110 and v110_xp toolsets is not a problem.

Answer 3

Please do not mix DLL having/exporting classes with different versions of Visual Studio (even minor version differences). STL and MFC have classes built on top of templates (classes itself may not be templatized for the user), which prevents linking and/or compilation between different versions.

A simple example would be CString: static and dynamic linking with MFC would have different CString implementations. Unicode and ANSI CStrings are also different. Another example is STL itself: Debug build vector is different than release build vector. Also, in case of STL collections, compiler settings would also change the size/implementation of container (like vector, list).

So, it better not to import export classes/functions having these type of classes as parameters. Don't even pass them in opaque way (like on top of a void-pointer).