Games for Windows and the DirectX SDK blog

Technical tips, tricks, and news about game development for Microsoft platforms including desktop, Xbox One, and UWP


Project maintained by walbourn Hosted on GitHub Pages — Theme by mattgraham
Home | Posts by Tag | Posts by Month

The Zombie DirectX SDK

dxsdk

Originally posted to Chuck Walbourn's Blog on MSDN,

Over the past five years, I’ve devoted significant time and effort to explaining the state of affairs with the legacy DirectX SDK. Developers can of course continue to use the legacy DirectX SDK (once they apply the workaround for the existing installation problems) with the Windows 8.0 SDK or later which comes with VS 2012 / 2013 / 2015 per the instructions on MSDN. This allows existing projects that still use deprecated D3DX9/D3DX10/D3DX11, XAudio 2.7, XInput 1.3, or XACT to build but still gain access to the latest Windows headers/libraries. You should in general rely on other methods for obtaining the latest debug device layer, tools, utility libraries, samples, Effects 11, DXUT11, and HLSL Compiler.

There is, however, one case that I’ve not addressed to date: A number of developers actually “checked in” the legacy DirectX SDK headers and libraries into their source control. While this behavior is a bit of a grey area in terms of the DirectX SDK EULA, it is none-the-less a widespread practice in the industry including several major game engines. In this case, the various recommendations I mentioned above are difficult to properly apply since typically headers/libs in your source control tree are going to take precedence over the platform headers/libs in the Windows SDK. Therefore, this article suggest how to modify these legacy DirectX SDK “mirrors” to get proper build behavior.

If you do not already have the legacy DirectX SDK headers/libraries submitted into your source control, I do not recommend doing so. This post is for people who already have and can’t simply delete it all without breaking supported scenarios. This is explicitly not an endorsement of the practice and I make no claims about whether or not this use is actually allowed by the terms of the DirectX SDK EULA.

Delete

The first step in this process is to delete the following legacy DirectX SDK headers & libraries completely. These are already provided by the Windows 8.x SDK when using the standard “v110”, “v120”, or “v140” Platform Toolsets, and are also provided by the Windows 7.1A SDK that is used when building with the “v110_xp”, “v120_xp”, or “v140_xp” Platform Toolsets that allow you to target Windows XP systems (see this post for more details). You do not need a private copy of these and the legacy DirectX SDK versions are out of date.

dxsdk\include\ D2D1.h
D2D1Helper.h
D2DBaseTypes.h
D2Derr.h
d3d9.h
d3d9caps.h
d3d9types.h
Dcommon.h
dinput.h
dinputd.h
dsconf.h
dsound.h
DWrite.h
DXGI.h
DXGIFormat.h
DXGIType.h
gameux.h
rpcsal.h
dxsdk\lib\x86\ d2d1.lib
d3d10.lib
d3d10_1.lib
d3d11.lib
d3d9.lib
dinput8.lib
dsound.lib
dwrite.lib
dxgi.lib
dxsdk\lib\x64\ d2d1.lib
d3d10.lib
d3d10_1.lib
d3d11.lib
d3d9.lib
dinput8.lib
dsound.lib
dwrite.lib
dxgi.lib

Keep

The next set of headers/libs are those that are unique to the legacy DirectX SDK and do not conflict with any of the headers/libs in the Windows 8.x SDK or Windows 7.1A SDK. You can safely keep these until you completely eliminate all use of legacy DirectX SDK content from your project. Also remember that you should not use any of these headers/libs for Windows Store apps, Windows phone apps, Xbox One apps, or universal Windows apps.

dxsdk\include\ audiodefs.h
comdecl.h
D3DX10.h
d3dx10async.h
D3DX10core.h
D3DX10math.h
D3DX10math.inl
D3DX10mesh.h
D3DX10tex.h
D3DX11.h
D3DX11async.h
D3DX11core.h
D3DX11tex.h
d3dx9.h
d3dx9anim.h
d3dx9core.h
d3dx9effect.h
d3dx9math.h
d3dx9math.inl
d3dx9mesh.h
d3dx9shader.h
d3dx9shape.h
d3dx9tex.h
d3dx9xof.h
dsetup.h
dxdiag.h
DxErr.h*
dxfile.h
dxsdkver.h
PIXPlugin.h
rmxfguid.h
rmxftmpl.h
xact3.h
xact3d3.h
xact3wb.h
XDSP.h
xma2defs.h
dxsdk\lib\x86\ d3dx10.lib
d3dx10d.lib
d3dx11.lib
d3dx11d.lib
d3dx9.lib
d3dx9d.lib
d3dxof.lib
dsetup.lib
DxErr.lib*
dxsdk\lib\x64\ d3dx10.lib
d3dx10d.lib
d3dx11.lib
d3dx11d.lib
d3dx9.lib
d3dx9d.lib
d3dxof.lib
DxErr.lib*

Windows 7

This next set of headers/libraries are only needed when targeting Windows 7 or earlier if you are using XAudio or more functionality for XInput than is provided in the basic 9.1.0 version of the API which is already present on Windows. This provides XAudio 2.7 (see this post) and XInput 1.3 (see this post). These headers/libs directly conflict with headers/libs in the Windows 8.x SDK, are not present in the Windows 7.1A SDK, and should be moved into a subfolder.

dxsdk\include\win7\ X3DAudio.h
XAPO.h
XAPOBase.h
XAPOFX.h
XAudio2.h
XAudio2fx.h
XInput.h
dxsdk\lib\win7\x86\ X3DAudio.lib
xapobase.lib
xapobased.lib
XAPOFX.lib
XInput.lib
dxsdk\lib\win7\x64\ X3DAudio.lib
xapobase.lib
xapobased.lib
XAPOFX.lib
XInput.lib

Note: The Windows 8.x SDK copy of xinput.h will use XInput 9.1.0 instead of XInput 1.4 if _WIN32_WINNT is set below 0x0602 (Windows 8.0). The legacy DirectX SDK xinput.h will use XInput 9.1.0 instead of XInput 1.3. if XINPUT_USE_9_1_0 is defined. The Windows 7.1 SDK copy of xinput.h only uses XInput 9.1.0.

Windows XP

Lastly, this set of headers/libraries are only needed when targeting Windows XP (i.e. building a EXE that can run on Windows XP as obviously Direct3D 10.x and Direct3D 11 are not supported on Windows XP). These headers/libs all conflict with the Windows 8.x SDK except XNAMath, are out of date compared to the Windows 8.x SDK, and should be moved into a subfolder. Some of these are not present in the Windows 7.1A SDK, while others are newer versions.

dxsdk\include\xp\ D3D10.h
D3D10effect.h
d3d10misc.h
d3d10sdklayers.h
D3D10shader.h
D3D10_1.h
D3D10_1shader.h
D3D11.h
D3D11SDKLayers.h
D3D11Shader.h
D3Dcommon.h
D3Dcompiler.h
D3DCSX.h
D3DX_DXGIFormatConvert.inl
xnamath.h
xnamathconvert.inl
xnamathmatrix.inl
xnamathmisc.inl
xnamathvector.inl
dxsdk\lib\xp\x86\ d3dcompiler.lib
D3DCSX.lib
D3DCSXd.lib
dxguid.lib
dxsdk\lib\xp\x64\ d3dcompiler.lib
D3DCSX.lib
D3DCSXd.lib
dxguid.lib

Note: DirectXMath will work on Windows XP, but there’s no official include path configuration that would support this scenario. You could in theory delete xnamath*.* and instead put a copy of DirectXMath*.*, DirectXCollision.*, DirectXColors.h, and DirectXPackedVector.* in this folder instead for Windows XP use. I make no claim that this is or is not allowed by the terms of the Windows SDK EULA.

Project Configuration

Assuming you had a dxsdk subtree configured as described above, then you should use the following as Additional Include Paths and Additional Library Paths in your project settings depending on your target platform if you have legacy DirectX SDK dependencies. Ideally you should minimize and work to eliminate all use of the legacy DirectX SDK in favor of the standard Windows SDK content.

  • For Windows Store apps, universal Windows apps, Windows phone apps, and Xbox One apps you should not use any of these paths in your build.
  • For Windows desktop applications built using the standard "v110", "v120", or "v140" Platform Toolsets--which will use the Windows 8.x SDK--and have ``_WIN32_WINNT`` set to 0x0600 (Windows Vista) or 0x0601 (Windows 7), then use:
    • Include: dxsdk\include;dxsdk\include\win7;%(AdditionalIncludeDirectories)
    • Libraries for "Win32" configurations: dxsdk\lib\x86;dxsdk\lib\win7\x86;%(AdditionalDependencies)
    • Libraries for "x64" configurations: dxsdk\lib\x64;dxsdk\lib\win7\x64;%(AdditionalDependencies)
  • For Windows desktop applications that do not make use of XACT; are built using the standard "v110", "v120", or "v140" Platform Toolsets; and have ``_WIN32_WINNT`` set to 0x0602 (Windows 8) or higher, then use:
    • Include: dxsdk\include;%(AdditionalIncludeDirectories)
    • Libraries for "Win32" configurations: dxsdk\lib\x86;%(AdditionalDependencies)
    • Libraries for "x64" configurations: dxsdk\lib\x64;%(AdditionalDependencies)
  • For a Windows desktop application that is compatible with Windows XP built using the "v110_xp", "v120_xp" or "v140_xp" Platform Toolset--which will use the Windows 7.1A SDK--and has ``_WIN32_WINNT`` set to 0x0501 (Windows XP), then use:
    • Include: dxsdk\include;dxsdk\include\win7;dxsdk\include\xp;%(AdditionalIncludeDirectories)
    • Libraries for "Win32" configurations: dxsdk\lib\x86;dxsdk\lib\win7\x86;dxsdk\lib\xp\x86;%(AdditionalDependencies)
    • Libraries for "x64" configurations: dxsdk\lib\x64;dxsdk\lib\win7\x64;dxsdk\lib\xp\x64;%(AdditionalDependencies)

Deployment

If you make use of these legacy DirectX SDK libraries, then you continue to depend on the legacy DirectSetup deployment mechanism to install these DLLs on end-user systems. See Not So DirectSetup and DXSETUP Update for more background on the proper use of this legacy deployment mechanism, and work to minimize your use of it.

  • Use of dxsdk\include for D3DX9_43.DLL, D3DX10_43.DLL, D3DX11_43.DLL, or XACTEngine3_7.DLL
  • Use of dxsdk\include\win7 for XInput1_3.DLL, XAudio2_7.DLL, XAPOFX1_5.DLL, or X3DAudio1_7.dll
  • Use of dxsdk\include\xp for D3DCompiler_43.DLL or D3DCSX_43.DLL

VS 2015 Users: Note that DXERR.LIB in the legacy DirectX SDK is not compatible with the C Runtime used by VS 2015. You must use this version of DXERR instead.