CTP of Windows XP Targeting with C++ in Visual Studio 2012

The three by-far-most-requested “missing features” from Visual C++ 2012 were:

  1. Conformance: Keep adding more C++11 language conformance features.
  2. XP Targeting: Deliver the ability to build applications that could run on Windows XP, as well as Windows Vista, 7, and 8.
  3. Desktop Express: Deliver a free VC++ Express compiler that can be used to create traditional Windows desktop apps, not just Windows Store apps.

Over the spring and summer, we promised to address these “soon after VC++ 2012 ships.”

Well, VC++ 2012 shipped four weeks ago.

What’s happened since then?

 

3. On the same day VS2012 shipped, four weeks ago, we also announced and released Visual Studio 2012 Desktop Express – a free Visual Studio version for writing traditional Windows applications.

 

image2. Today, we are pleased to share a “community tech preview” (CTP) of Windows XP targeting in Visual C++ 2012, being delivered as part of Visual Studio 2012 Update 1 CTP 3. You can download the preview here. See the announcement page for details, known issues, and full release information.

 

1. Stay tuned…

16 thoughts on “CTP of Windows XP Targeting with C++ in Visual Studio 2012

  1. No need for static linking. the new versions of vcredist_x86.exe (not yet released but will be in November with the final), msvcr110.dll, mfc110, etc work just fine under XP. Not sure where you got the idea that static linking was required for this new XP targeting solution.

  2. Guys, the XP stuff works with the Windows 8 SDK. No need to change to the other platform toolset if you really don’t want to. I have done a lot of testing with very large projects. The reason they do this (state that the separate 7.1 SDK toolset is required) is to protect themselves for future “breaks” of the Windows 8 SDK, so they don’t have to ask the Windows team to support Windows XP in the Windows 8 SDK. But unofficially, it supports it fine. The ONLY change you need to make to your project is to change the linker subsystem from 6.0 to 5.01. That’s it. Of course, Windows 8 SDK has removed a lot of obsolete headers, such as MAPI, outlook headers, etc. So if you really want to support those old headers, use the 7.1 SDK toolset.

  3. @John: This decision is likeyl beyond the scope of the Visual Studio team. For the PSDK guys, this would mean they have to support XP with every update of the SDK – remember, the SDK isn’t just headers. *I* wouldn’t want to make that promise.

  4. I don’t think it’s unreasonable for the latest SDK to “only” support 3 versions of Windows. They have to draw a line somewhere!

  5. “because we had to target a different SDK”

    You didn’t *have* to — you chose to.

    “Windows 8 SDK has officially dropped support for Windows XP and Windows Server 2003”

    From my perspective, that’s a bug in the Windows 8 SDK. A bug reported long before the product shipped, that could have been fixed before RTM if you wanted to. Instead, you made a choice to “support” XP with the least work possible (least work for you, not least work for ISV’s).

  6. Re why ship this as a distinct toolset: It’s because we had to target a different SDK. One of our team members has responded with more details on the linked blog post’s comments… repeating here:

    [Ibrahim Damlaj] 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. [Y]ou 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.

    So to ensure that XP targeting really does create binaries that can run on XP, you have to target the Windows 7 SDK, and that means a different toolset target.

  7. I have WDExpress Desktop. No TFS (none wanted). I do want XP target. What do I download for that, and only that? I had to test on XP today and found out the PE is not a PE anymore; it’s an abomination! Apparently. XP thinks so.

  8. Good news, and things are gonna get better in the future… and Im not a insider or naive…
    Why do i say that then you might ask… because of a certain fruit company :) that dumped a lot of money into a certain compiler so MS must dump money in VC++ or it will become irrelevant for native devel on Win, what is ofc unacceptable.

  9. Great news! We still have to support a lot of XP machines and we are very exited about the new features of VS2012. Finally we can use them too…

  10. Too bad it requires Yet A Build Target, requires an older SDK, and doesn’t support remote debugging.

    But at least it’s a step in the right direction, compared to the clusterf**k “multitargetting” of previous versions. Kudos for listening to your users and at least doing an honest attempt :)

  11. Hugely disappointed that Microsoft introduced a new toolset to handle XP. Are you trying to make XP support painful? 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.

  12. The Windows XP stuff is great and I’ll be trying out a build of our product with it this week, but I’m super interested to hear about the Standard conformance improvements. Come on Herb, don’t be coy :-)

  13. Oh, nice! Let’s hope Boost adds support for this toolset soon and I think a lot of people will be very happy.

Comments are closed.