The Zombie DirectX SDK


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.

Comments (6)

  1. Zubair Khan says:

    Waooo! A great post. It is a great hard work you have done. It appreciate your hard work. Project confugration also you discus in detail. It is great thing.

    http://www.ben10games.pk

  2. Voodooman says:

    Its amazing how lazy and shortsighted MS become nowadays, you guys cant even properly deploy your own software and api on your own os in automated fashion and solve these with installer of SDK and instead suggesting end users to do everything manually. And people who are not reading your blog would not be even aware they doing something wrong, because actualy you – MS guys did a lot of things wrong.

    Its sad but somewhere since 2010 you totally ruined DirectX and you manage to ruin it even more with every major os release and totally stopped to care about updates of DX for pre-last version of Windows which are dominant in market, and everything is done just ot push totally ruined Win 8 that everybody hates. Your attempts to push out better and last goo Windows – 7 and replace it with 8 and now 10 just so pathetic. Its time to say it good bye and never ever use any MS api and use open cross platform alternative such as OpenGL(next one too), OpenAL, OpenCL, SDL and so on.

    What a shameful time – Wine D3D libs  designed for Linux and compiled for windows that wraps around D3D games to OGL are way more compatible and accurate than your own API libs. So many not so old (like 6-8 years old) games are broken in WIn 8 and 10 in DirectX department, yet even Oldest OpenGL powered games such as GLquake still works like charm 20 years after.

    I wish all devs to stop using MS apis until someone in your screwed company would start to care about making everything future proof and backward compatible.

  3. Vodo killer says:

    Vodo : dont like it, dont use it.. mean and lean…

  4. Azarien says:

    If you didn't remove "deprecated" files from the SDK, life would be easier.

    You can't assume that everyone will immediately start targeting the newest DirectX and Windows foregoing "legacy" versions.

    The ability to compile old code with the newest compiler and headers is important.

    But since the "DirectX SDK" is a moving target (or a target farther and farther away in the June of 2010) the easiest way is to check in the damn libs and headers.

  5. All of the headers in the "Delete" section already have newer versions in the standard Windows 8.x SDK and Windows 10 SDKs that come with Visual Studio 2012 or later. The DirectX SDK versions are totally obsolete, which is why this article is strongly recommending that if you do check them in, you delete those because they are the *wrong versions* now.

    The DirectX SDK (June 2010) included bits for Direct3D 9 development which is essentially only applicable to Windows XP, and Direct3D 10 development which is fully supplanted by Direct3D 11. Everything you need for Direct3D 11 is either in the Windows 8.x SDK / Windows 10 SDK or covered by an open source replacement on GitHub.

    In other words, you might well end up trying to use 'deprecated' files for years beyond their actual useful life, which is why checking them can be a problem if you never take the time to see if they are still correct.

    Furthermore, just because you 'check in the headers & libs' doesn't actually mean that someone enlisting to your source tree can avoid installing the legacy DirectX SDK. Remember that XAudio 2.7, XInput 1.3, XACT, D3DX9, D3DX10, and D3DX11 are never part of the OS itself and must be deployed by the legacy DirectSetup anyhow. If you move to the modern replacements, you don't have any dependencies on non-OS DLLs (except maybe D3DCompile which you can just include side-by-side with your Windows desktop app).

    I get that change is work, and there's lots of change for developers to absorb all the time, but unless you are specifically trying to target an OS really only well suited for PCs frozen in amber in ~2004 then the current development story is generally much cleaner now than it was in the heyday of the DirectX SDK. You install Visual Studio and maybe grab some open source libraries via GitHub or NuGet and you are good to go for DirectX 11 development.

    If you are still targeting Windows XP, then you are basically doing the same thing now that you did in 2010 or before: You install Visual Studio which comes with the Windows 7.1 SDK when using the xp Platform Toolset, you install the legacy DirectX SDK and set up the paths as you always have. The only significant change here is that you can't get debugging support for Direct3D 9 on Windows 8 or later, but you are already going to need a Windows XP machine to remote debug to anyhow to have any confidence the code you are writing really works on such an ancient environment.

    1. Robin says:

      I’m an old dx developer which stopped at dx9 (bcos of the mess its became). Now I’m back with to do some work with dx11 and using vs2015, and yup, d3dx9 is removed and can’t be found anywhere online. So I wished I had checked that in version control.

Skip to main content