In June, we announced enhanced targeting for Windows XP using the Visual Studio 2012 C++ compiler and libraries. This feature has been included in Visual Studio 2012 Update 1. You can download it from here. The purpose of this article is to provide an overview of the Windows XP targeting experience, the level of C++ runtime support, and noteworthy differences from the default experience shipped in Visual Studio 2012 at RTM.
In order to target Windows XP, switch from the default v110 toolset to the newly introduced v110_xp toolset inside your project’s property pages. This new platform toolset points to a repackaged version of the Windows 7 SDK shipped in Visual Studio 2010 instead of the Windows 8 SDK, but uses the same Visual Studio 2012 compiler. The v110_xp toolset also sets useful defaults such as a compatible linker subsystem version for downlevel targeting. Only executables built with this platform toolset are supported to run on Windows XP, but those same executables will also run on Vista, Windows 7 and Windows 8.
The static and dynamic link libraries for the CRT, ConCRT/PPL, STL, and MFC have been updated in-place to add runtime support for Windows XP and Windows Server 2003. Applications written in C++/CLI which target the .NET Framework 4.0 will also run on Windows XP and Windows Server 2003. For these operating systems, the supported versions are Windows XP SP3 for x86, Windows XP SP2 for x64, and Windows Server 2003 SP2 for both x86 and x64.
v110 (Store Apps)
Visual Studio 2012 solutions and projects which have been switched to the v110_xp toolset can be built from the command line using MSBuild or DEVENV without additional steps.
However, if you wish to use CL and Link directly, additional steps are needed. Note that the steps below may be automated by creating a batch script.
As always, we'd love to hear your feedback. Please submit bugs to Visual Studio Connect, and suggestions to Visual Studio UserVoice.
> This new platform toolset points to a repackaged version of the Windows 7 SDK shipped in Visual Studio 2010 instead of the Windows 8 SDK, but uses the same Visual Studio 2012 compiler.
does it mean I need to have VS2010 installed to use this ??
@WalkingCat: No, the repackaged SDK is included with the update.
Is any plan to support C++ AMP for final release, with only CPU fallback on XP ?
Out of curiosity, what was the reason for needing to switch to the Windows 7 SDK when building for XP? The compiler is the same and the runtime libraries have been revved to support XP, so I wonder what the blocker was. Using the Windows 7 SDK does mean that it will be more difficult to use Windows 8 functionality from an XP-compatible program, which may be unusual but is possible.
Is there any additional C++ language features supported in this update?
@Jackson: The update description page (at the bottom of my post) says no. I'm guessing the C++11 out-of-band updates are going to be a separate update to the Visual Studio update (it's not a "Service Pack" any more?), in the same manner as the web team have been releasing their updates through NuGet.
OT: This is nice, I've got an XP-required project that it will be nice to be able to move to the 2012 compiler, if only for the smarter editing. (Also, I don't have to install 2010 when I wipe my machines sometime later). Having variadic templates & friends will probably be a bigger deal, when that stuff comes through.
WHEN can we expect "the next release of Visual Studio 2012 Update 1"?
(Apologies if this is a repost, but I think the ancient MSDN "swallow your post if it wasn't submitted within a few seconds of loading the page" bug is still there, so I'm posting again.)
It's never been made particularly easy to build EXEs that can run on old versions of Windows while taking advantage of newer APIs as available (at least if you want the compiler to tell you when you accidentally use new APIs/structs/etc. in common code paths), something that I'd love to see Visual Studio improve upon in future versions.
Forcing the old SDK + tools to be used, and a separate build/project type, when targeting XP is not helping at all. That makes things worse, not better. More complicated, not less.
Remote debugging tools are also essential for XP targeting, for me. I don't have an XP development machine set up and maintained; I just have XP running in a VM to test on, and if something goes wrong and I need to debug it then I want to use remote debugging, not to have to install Visual Studio + updates + SDKs + all my source + other tools inside the VM. That takes hours, gets in the way of snapshots/rollbacks, makes it harder to test that my binaries don't have accidental dependencies on something installed by Visual Studio, is inconvenient compared to VM on one monitor and VS on another, etc. etc. etc.
Instead of kludging in a repackaged version of the old runtime + toolset, why can't you fix the new runtime + toolset to work on Windows XP? Is it really that difficult? Maybe it is. But if so then, at least for me, it makes more sense to stick with VS2008 or VS2010 for a couple more years, until XP finally dies in 2014 (yipee), than to mess around with this type of half-baked solution. Sorry.
@Leo Davidson, the only difference is the SDK headers and libs, not the CRT/MFC headers and libs, nor the toolset. The toolset is the same, but the SDK 8.0 doesn't support XP (officially), only the 7.1 SDK does.
I got it to work fine with 8.0 SDK and changing the linker settings manually, but this is not a supported (by Microsoft) scenario.
The redist (runtime, e.g. msvcr110.dll) is the same for all platforms, no separate redist for XP.
So all you're getting with the vc110_xp is the 7.1 Windows SDK headers and libs and a few changes to linker subsystems, etc to target XP. VC2012 MFC, CRT, etc are the same for ALL platforms including XP.
Very nice to see promises being kept.
Leave it to Microsoft to screw this up. There's no excuse for introducing a new toolset to handle XP. If some damn fool broke the SDK headers in Windows 8, (1) said fool should be fired (which will make Mini-MSFT happy), and (2) the headers should be fixed. The SDK headers are already full of #ifdef's to selectively expose API's based on target OS version. Shipping the Windows 7 headers is a huge kludge to avoid doing the job properly.
@John: that's crappy solution similar to what they have done to produce smaller MFC executable due to ribbons feature that almost noone use. And that's nothing compared to C++/CX junk that was highly unnecessary with clever C++ paradigms that exist today.
It was pretty funny to read at Pat Brenner's blog how he tried to explain this were sound decisions. :-D
The reason we have reintroduced the Windows 7 SDK is that the Windows 8 SDK has officially dropped support for Windows XP and Windows Server 2003. What this means is that the binaries under the “Windows Kits/8.0/bin” directory are no longer guaranteed to generate code that runs on Windows XP/2003. Additionally, the Windows 8 SDK headers and libs may have removed deprecated Windows XP APIs with no mitigation. As @Mike described above, you may choose to target the standard SDK by not switching to v110_xp. However, if your application compiles and runs we cannot guarantee it will continue to do so in future releases and updates of Visual Studio.
"The reason we have reintroduced the Windows 7 SDK is that the Windows 8 SDK has officially dropped support for Windows XP and Windows Server 2003. "
And your point is?
Visual Studio 2012 officially dropped support for Windows XP and Windows Server 2003, and then put it back.
Could you spell out the linker options required to target XP while using the VC110 toolset? Is the following sufficient?