4

In order to deploy C++ application built with VS2013 compiler under Windows XP, the "v120_xp" platform toolset has to be set: this make it possible the deployment from XP to 8.1. So next come the question: why this platform toolset is not the only one and the default? The "v120" platform toolset is suitable starting from Windows Vista. Is there any performance drawback? I've tested an application built towards both the platform toolsets under Windows 8 but I've seen no difference in performance (apparently..).

ABCplus
  • 3,981
  • 3
  • 27
  • 43
  • 1
    No, performance is not affected. Compatibility is the big deal. – Hans Passant Jun 16 '14 at 11:04
  • What do you mean for compatibility? v120_xp platform toolset supports from Windows XP to 8.1 – ABCplus Jun 16 '14 at 11:46
  • 1
    I'm confused about what *your actual question is* here. Are you asking what it means to choose "v120_xp" as your platform toolset? Are you asking what the disadvantages are? Are you asking how to make this setting the default for new projects? There could be a good question here, it is just not explained very well. Consider [edit]ing. – Cody Gray - on strike Jun 16 '14 at 19:46
  • @CodyGray: What I'm asking is why this platform toolset (v120_xp) is not the default, since it makes your C++ project running in OS from Windows XP to Windows 8.1. The default one is the v120, not compatible with Windows XP. I belive that most developers still needs to support Windows XP with C++ projects, so I can't understand why somebody could choose the v120. – ABCplus Jun 17 '14 at 07:25
  • 2
    It can be the strategy marketing issue. If developers will deploy application not compatible with windows XP, Microsoft can finally "kill" Windows XP and sell more Windows 8. This can be the reason it is default. – Tomas Kubes Jul 23 '14 at 07:10

1 Answers1

7

There are quite a few things you just can't do with the XP-dedicated toolset - it makes use of old headers and libraries, and so apps built with it just can't call a lot of newer APIs and use some fancy newer tools. A notable example is DirectX - quoting this MS page:

When building applications that support the legacy Windows XP platform, you are using a platform header and library set similar to those that shipped in the Windows 7.1 SDK rather than the Windows 8.x SDK with the integrated DirectX SDK content (see Where is the DirectX SDK?). Many of the "DirectX" headers and libraries are included with these Windows XP compatible platform headers (see DirectX SDKs of a certain age) such as Direct3D 9, DirectSound, and DirectInput. You will, however, need to continue to use the legacy DirectX SDK for Windows XP compatible versions of the D3DCompile API (#43), legacy D3DX9, XAUDIO2, XINPUT, and PIX for Windows tool (the Visual Studio 2012 Graphics Debugger does not support Direct3D 9 applications).

Windows SDK 7.1A is installed as part of VS 2012 Update 1 for use with the "v110_xp" Platform Toolset, which contains the headers, libraries, and a subset of the tools that originally shipped in the Windows SDK 7.1. There are older Direct3D 10 and Direct3D 11 headers as part of this 7.1 era toolset which are outdated compared to the Windows 8.x SDK versions using the standard "v110" Platform Toolset, particularly the SDK Debug Layers installed by the Windows 8.0 SDK on Windows 7 and Windows 8. The Platform Toolset "v110_xp" is therefore not recommended for developing DirectX 11 applications, but it can technically be done with some caution. Windows SDK 7.1A does not contain a dxguid.lib so must either locally define the required GUIDs in your project by using define INITGUID in one of your .cpp files, or use the legacy DirectX SDK version.

Ofek Shilon
  • 14,734
  • 5
  • 67
  • 101