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.
I'm guessing there is no symbol files for the replacement DLLs that aren't source-stripped yet?
Those are correct - and interestingly it seems that you only need them on EXEs. I noticed msvcr110.dll etc are still marked as 6.0 but they load fine under XP as long as the EXEs are marked with the correct subsystem. And don't forget to use /SUBSYSTEM:CONSOLE (with version number) instead of /SUBSYSTEM:WINDOWS if building a console app.
Thanks for listening to feedback and including XP support with C++11.
I tried to test writing a simple HelloWorld kind of statically built application ( i.e., using /MT ) using the "v110_xp" platform tool set. When I tried to run the executable on XP SP3, I get an error window popup saying "HelloWorld.exe is not a valid Win32 application."
Please test the project I have uploaded at Skydrive (skydrive.live.com).
Am I doing something wrong ?
@Mahesh V I noticed that in your project properties - Linker - System - Subsystem field, the "Console" is blank. I could not reproduce this when generating a new Win32 console app. If you set you linker subsystem to "Console" it should fix your problem. Can you describe the steps you took that caused this to go blank (can you post a project before you converted it and before changing the "Platform Toolset" to "Visual Studio 2012 - Windows XP (v110_xp)).
@Mike Not sure why "Configuration Properties -> Linker -> System -> Subsystem" properties is blank on my machine. Even if I create a new project ( which uses v110 toolset by default ) , the option is blank. I have VS 2005 installed on my system as well. Not sure if this has anything to the issue. BTW, the executable ran fine after setting the Subsytem option on XP. I amn't sure though why this is a requirement on XP but not on Vista +
Thanks for the help.
@Mahesh V: Hi Mahesh. I am trying to troubleshoot why Subsytem isn't being populated for you. Are you using Windows Desktop Express 2012 or a VS Retail SKU? Was Subsystem being populated prior to installing VSUpdate CTP3?
I am using VS 2012 Ultimate Edition and I applied the XP support update to it. I am not sure whether the "Subsytem" option was blank previously or not.
Actually, I was migrating VS 2005 solution file to VS 2012 prior to this update. I built the converted file. Then the executable wasn't running on XP citing reason of not a valid Win32 application. A bit of googling and this Stackoverflow answer (stackoverflow.com/.../xxxxxx-exe-is-not-a-valid-win32-application) suggested me that the applications built on VS 2012 doesn't run on XP. That seemed a valid reason for me.
Then on applying the XP update, I ran into the same issue. And Mike found it's a Subsystem option issue. I wonder even if not applying the XP update, a statically built application on VS 2012 would have run fine on correctly setting Subsystem option.
If it were made strait-fwd there would be fewer who would say the el with xp and that is not part of the end game now is it. No remote debug makes it all rather pointless now doesn't it. Used to use debug.com. Better than nothing it was. Now there is nothing.
BTW, why is the find so slow? The find in-the-little-box find. The other find is as before. The little box find should be taken out back and (...) buried.
I have seen no speed increase (talking compiles). At least it's cpu bound. But mostly just one.
And Help. When it starts it's as if I have a runaway driver taking 99 pct CPU. It goes on a while. Copy (text selection) is broken when menu selected. Ctrl-Ins does not work, either (not unsual). HAVE to use ^c. Help v 2.0 in general is one kluncky pieoce of - software. It acts peculiar. At least it shows content properly (if you let IE execute based on content rather than extension (pfffff)), unlike in my 125% browser where so often now the page is cut off at right. And no it will not pan.
Oh, you want the mic? Go ahead. Good luck if it posts.
@MaheshBabuV: If the new project you create is an Empty Project, the IDE has no idea if it is going to be a Console project or Windows Project, so the Subsystem is blank and will need to be set by the user to specify which kind of project is being compiled. If you create a new Console Application in VS 2012, is the Subsystem then populated?
Now I see what you said. I thought while selecting a "Visual C++ -> General -> Empty Project", the property "SubSystem" would take some default value. It is not the case.
While creating the project as a "Console Application", appropriate option for "SubSystem" is selected.
Using (Win32): "/SUBSYSTEM:WINDOWS,5.01" (added linker switch) I get
which makes that a nogo
That was cut-n-aste from earlier here. It is a console so I used this added linker switch
This msdn page
shows the default subsystem for vs 2012 as 5.0 (x86). The exe header is marked 6.0, though. Weird. But doesn't help.
One of the main reasons given by Microsoft that the new CRT for VC11 doesn’t run on XP is their deliberate move from locale identifiers (LCIDs) to locale names.