Windows XP Targeting with C++ in Visual Studio 2012

Windows XP Targeting with C++ in Visual Studio 2012

Rate This
  • Comments 42

Background

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.

Windows XP Targeting Experience

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. 

C++ Runtime Support

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.

Library

v110 (Vista+)

v110 (Store Apps)

v110_xp (XP/2k3+)

CRT

X

X

X

ConCRT/PPL

X

X

X

STL

X

X

X

MFC

X

 

X

ATL

X

X

X

C++ AMP

X

X

 

Differences from Vista+ Targeting

  1. Building HLSL
    Building HLSL with the v110_xp toolset is not enabled by default. To enable HLSL compilation, download the DirectX SDK (June 2010) and set your project’s VC directories manually to point to this SDK, in a similar manner as Visual Studio 2010. For more information, see the “DirectX SDK Does Not Register Include/Library Paths with Visual Studio 2010” section of the DirectX SDK (June 2010) download page.
     
  2. Debugging DirectX
    The Visual Studio 2012 Graphics Debugging experience is not supported when targeting DirectX 9.
     
  3. Static Analysis
    When selecting the v110_xp platform toolset, the static analysis experience is disabled due to incompatibilities between the SAL annotations in the Visual Studio 2012 C++ libraries and the Windows 7 SDK. If static analysis is required, we recommend that you switch the solution to the normal v110 toolset, execute static analysis, and then switch back to v110_xp.
     
  4. Remote Debugging
    The Remote Tools for Visual Studio 2012 do not support remote debugging on an XP client. When debugging on Windows XP is required, it is recommended to use the debuggers of an older version of Visual Studio, such as Visual Studio 2010, for local or remote debugging. This is in line with the Windows Vista experience for Visual Studio 2012 RTM, which is a runtime target but not a remote debugging target.

  5. Process Status APIs
    As with Visual Studio 2012 RTM, applications that target Windows Vista and below while taking a dependency on the process status APIs must set  the PSAPI_VERSION macro to 1.

Targeting from the Command Line

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.

  1. Set the path and environment variables for Visual Studio 2012 command-line builds. 

  2. Set the required SDK paths and compiler flags using the following commands:

    set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE%
    set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH%
    set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB%
    set CL=/D_USING_V110_SDK71_;%CL%

    When targeting x64, set the lib path as follows:
    set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB%
     
  3. Specify the correct subsystem and subsystem version for the linker based on the type of application you are building. Applications targeting the x86 version of Windows XP must specify subsystem version 5.01, and applications targeting x64 must specify version 5.02.

    For x86 console applications: 
    set LINK=/SUBSYSTEM:CONSOLE,5.01 %LINK%

    For x64 console applications:
    set LINK=/SUBSYSTEM:CONSOLE,5.02 %LINK%
     
  4. Execute CL and Link as you normally would within the command prompt.

Feedback

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?

    Thanks, Chris

  • @Chris Hubbard

    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?

    Thanks, Chris

  • @Chris Hubbard

    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.

    Thanks,

    Mahesh.

  • Using (Win32): "/SUBSYSTEM:WINDOWS,5.01" (added linker switch) I get

    <img src="imageshack.us/.../noenumsystemlocalesex.png">

    which makes that a nogo

    imageshack.us/.../noenumsystemlocalesex.png

  • That was cut-n-aste from earlier here.  It is a console so I used this added linker switch

    /SUBSYSTEM:CONSOLE,5.01

    FTR

  • This msdn page

    msdn.microsoft.com/.../fcc1zstk(v=vs.110).aspx

    shows the default subsystem for vs 2012 as 5.0 (x86).  The exe header is marked 6.0, though.  Weird.  But doesn't help.

    FYI

  • :

    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.

    :

    http://supportxp.com/2012/04/

Page 2 of 3 (42 items) 123