DirectX SDKs of a certain age


Recently many older releases of the DirectX SDK and REDIST packages expired and were removed from the Microsoft Downloads Center site. The DirectX SDK and REDIST packages for all 2008, 2009, and 2010 releases are currently available, but all 2007 and prior releases are no longer hosted by Microsoft.

Here is a quick summary of DirectX technologies and recommended solutions. Be sure to read Where is the DirectX SDK? and Where is the DirectX SDK (2013 Edition)? as well.

Technology Resolution
Direct3D 11.3/11.4
Direct3D 12
The Windows 10 Anniversary Update SDK (14393) includes Direct3D 11.3, Direct3D 11.4, Direct3D 12.0, Direct2D 1.3, DXGI 1.4, and DXGI 1.5.

The DirectX 12/11.3/11.4 Runtime is included with Windows 10.

Direct3D 11.2 The Windows SDK 8.1 includes Direct3D 11.2, Direct2D 1.2, and DXGI 1.3.

The DirectX 11.2 Runtime is included with Windows 8.1 / Windows Server 2012 R2.

Direct3D 11.1 The Windows SDK 8.0 includes Direct3D 11.1, updated Direct2D/DirectWrite, updated WARP, and DXGI 1.2.

The DirectX 11.1 Runtime is included with Windows 8 / Windows Server 2012. Partial support is available down-level on Windows 7 / Windows Server 2008 R2 Service Pack 1 via KB 2670838.

Direct3D 11.0 The Windows SDK 7.0 includes Direct3D 11.0, Direct2D, DirectWrite, WARP, and DXGI 1.1.

The DirectX 11.0 Runtime is included with Windows 7 / Windows Server 2008 R2. Support is available down-level on Windows Vista / Windows Server 2008 Service Pack 2 via KB 971644.

Direct3D 10.x The Windows SDK 6.0 or later includes Direct3D 10.x and DXGI 1.0.

The DirectX 10.0 Runtime is included with Windows Vista / Windows Server 2008. The DirectX 10.1 Runtime is included with Windows Vista / Windows Server 2008 Service Pack 1.

Windows SDK 7.0 or later includes updates for expanded Direct3D 10.1 feature levels (aka "10level9") included with the DirectX 11.0 Runtime.

Direct3D 9 Windows SDK 6.0 or later includes Direct3D 9 and Direct3D9Ex.

Direct3D 9.0c is included with Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, and Windows XP x64 Edition.

Direct3D9Ex is supported by Windows Vista / Windows Server 2008.

Direct3D 8 and prior The August 2007 DirectX SDK was the last version to include Direct3D 8 (d3d8.h d3d8caps.h d3d8types.h) and Direct3D 7 and prior (d3d.h d3dcaps.h d3dvec.inl d3dtypes.h).

Direct3D 9 or later should be used for all applications, and we'd recommend using Direct3D 11.

D3DX The June 2010 DirectX SDK contains the last release of D3DX9, D3DX10, and D3DX11.

DirectXMath, DirectXTex, DirectXMesh, and D3DCompile replace the majority of the functionality in these utility libraries. DirectXTK provides further alternatives for Direct3D 11 applications. For Direct3D 9 applications, the DDSWithoutD3DX sample provides a way to create textures from .DDS files.

The Effects 11 library is available as shared-source online.

See Living without D3DX for a master list of D3DX replacements.

DXERR9.LIB The August 2007 DirectX SDK was the last version to include the dxerr9.lib. It has been replaced by dxerr.lib in June 2010 DirectX SDK which supports all the same error codes plus some new ones. Changing references to dxerr.lib or making a copy as dxerr9.lib should resolve link issues for this library.

Note for Windows 8.x SDK users, see this post for a replacement solution.

XACT The June 2010 DirectX SDK contains the last release of the Xbox Audio Cross Platform Tool (XACT) for Windows.

For games, we recommend using XAudio2 or a 3rd party middleware solution instead.

DirectDraw While February 2010 DirectX SDK was the last to contain ddraw.h and ddraw.lib, ddraw.h is still available in the Windows SDK 6.0 or later. ddraw.lib isn't needed.

See Wither DirectDraw for details.

DirectInput The August 2007 DirectX SDK was the last version to include DirectInput7 and prior (dinput.lib). DirectInput8 (dinput.h dinput8.lib) is available in the Windows SDK 7.0 or later and is supported for both x86 and x64 native Win32 desktop applications.

For gamepads, we'd recommend supporting XINPUT. XINPUT 9.1.0 headers and libraries are available in the Windows SDK 6.0 or later. See this post for additional information. For mouse and keyboard input, you should use standard Windows messages rather than DirectInput as well.

DirectSound DirectSound8 (dsconf.h dsound.h dsound.lib) is available in the Windows SDK 7.0 or later and is supported for both x86 and x64 native Win32 desktop applications.

For games, we recommend using XAudio2 instead. Audio engines with their own mixing engine and source rate conversion (SRC) support should use WASAPI on Windows Vista or later.

DirectMusic The August 2007 DirectX SDK was the last version to include DirectMusic, and the DirectMusic Producer tool download is no longer hosted by Microsoft. Use of DirectMusic for games is not recommended.

"Core" DirectMusic headers (dls1.h dls2.h dmdls.h dmerror.h dmksctrl.h dmusbuff.h dmusicc.h dmusics.h) for use by professional audio developers are available in the Windows SDK 7.1 or later, and supported for both x86 and x64 native Win32 desktop applications by Windows 7 and Windows 8.

DirectShow The February 2005 DirectX SDK was the last to include DirectShow headers, but these are available in the Windows SDK.

Media Foundation available on Windows Vista and later versions of Windows is recommended over DirectShow for video playback. Be sure to read this post for some additional considerations.

DirectPlay The August 2007 DirectX SDK was the last version to include DirectPlay (dpaddr.h dplay.h dplobby.h dplay8.h dplobby8.h dpnathlp.h dplayx.lib). The DirectPlay NAT helper is not supported on Windows Vista or newer versions of Windows.

For games we recommend using TCP/IP via the WinSock API for network communication. To replace the 'lobby' functionality, you can utilize any number of the many game services available today from Microsoft and other vendors.

DirectAnimation The August 2007 DirectX SDK was the last version to include dxtrans.h and dxtrans.lib.

This technology was used at one point by Internet Explorer, but this is no longer in use.

Managed DirectX 1.1 The August 2006 DirectX SDK was the last version to include the samples and documentation for Managed DirectX 1.1.

See DirectX and .NET for more information.

Direct3D Retained Mode The August 2007 DirectX SDK was the last version to include d3drm.h d3drmdef.h d3drmobj.h d3drmwin.h.

This component is not supported on Windows Vista or newer versions of Windows (see KB 969150).

DirectPlay Voice The August 2007 DirectX SDK was the last version to include dvoice.h.

This component is not supported on Windows Vista or newer versions of Windows (see KB 970978).

DirectX 7/8 Visual Basic 6.0 The August 2007 DirectX SDK was the last version to include dx7todx8.h.

This component is not supported on Windows Vista or newer versions of Windows (see KB 971028).

DirectSetup: For the REDIST package, the current web redist and standalone package will install all older and current verisons of the various optional side-by-side DLLs on Windows XP Service Pack 2 or later. See Not So Direct Setup for more details and notes about older releases.

Dark GDK: For users of the Dark GDK that was promoted for Visual Studio 2008 Express, the retirement of the DirectX SDK (August 2007) poses some challenges. There are some community work-arounds for disabling the use of DirectPlay and resolving the link problems with DXERR9.LIB (such as this post), and these are preferrable to continuing to use a copy of the DirectX SDK (August 2007).

DirectX SDK (August 2007): If you obtain a copy of this package from an unofficial mirror, be very careful as installing executables that require administrator privledges from untrusted websites carries a potential risk of adding your machine to a botnet and getting infected by other malware. Check that the EXE is signed with a valid Microsoft Digital Signature before running it. These unofficial mirrors are not supported or sponsered by Microsoft.

VS 2005: Windows 7.1 SDK and DirectX SDK (February 2005) were the last releases to support Visual Studio 2005.

VS 2008: Windows 7.1 SDK and DirectX SDK (June 2010) were the last releases to support Visual Studio 2008.

VS 2010: Visual Studio 2010 comes with the Windows 7.0 SDK included. You can make use of the Windows 7.1 SDK with VS 2010 by using a Platform Toolset setting. You can use the Windows 8.0 or 8.1 SDK by creating a property sheet for your project.

VS 2012: Visual Studio 2012 comes with the Windows 8.0 SDK included. Mixing the Windows 8.x SDK with the legacy DirectX SDK requires some specific build settings.

VS 2012 Update 1: Support for Windows XP the "v110_xp" Platform Toolset makes use of a Windows SDK 7.1A which is basically the same as 7.1.

VS 2013: Visual Studio 2013 comes with the Windows 8.1 SDK included.

Related: A Brief History of Windows SDKs

Comments (8)

  1. vckzdd@gmail.com says:

    Excellent details!

  2. Mike says:

    However, I frequently come across code that needs those older versions to compile. May I suggest Microsoft allowing at least other sites to host those files if Microsoft no longer want to be responsible for them (For reasons I very well understand) ? I think it is interesting because of archival (historical) reasons as well.

  3. Pissed@Microsoft says:

    Give how critical the August 2007 DirectX SDK is for legacy applications and code, I can't believe that MIcrosoft refuses to host a copy of it especially given how cheap storage and bandwidth are.

    Host the August 2007 DirectX SDK, you MS cheapasses!

  4. The reason that downloads on MSDN are not archived indefinitely is because the intent is to allow a reasonable transition period for developers, not to support building applications using deprecated APIs indefinitely. Which technology in particular is your legacy code still using?

  5. Against Copouts says:

    Part 1: "The reason that downloads on MSDN are not archived indefinitely is because the intent is to allow a reasonable transition period for developers, not to support building applications using deprecated APIs indefinitely. Which technology in particular is your legacy code still using?"

     Is a cop out, that is their excuse to force developers to write new code to force manufacturing vendors to make new hardware which will in essence force developers to write new code all in order to keep the public (consumers) to continuously keep purchasing new devices every couple of years. Don't get me wrong; I don't mind advances in technology when those advances are extremely significant but let's face the facts; it is one of the largest money generating rackets. For example; they try to discourage people from designing code in pure C, now they are trying to push C++ away from its original concept (paradigm) yet if we look back to before I was even born back in the 70s; yes the machines weren't quite as powerful nor could they do as many computations as our current machines, but these relic languages worked then and they still work today! It was before my time, but at one time or another almost every program was written by developers in ASM long before any high level languages were developed, but then again they were using the old punch card systems. What is going to happen in another 20 – 30 years from now when some of these older systems that are still in place that rely on these antiquated or relic languages need programming maintenance such as the control systems within nuclear power generating facilities where most developers in that time have no idea how to program in assembly, c, cobal, fortran, pascal, pearl, etc., since a majority of that won't even be taught any more. Now, these libraries that have been marked as deprecated shouldn't be discarded, they should be listed in an archive and any errors or vulnerabilities in those libraries should be fixed! Yes if you are developing software for a new device then it would be advised to not used these deprecated resources, but sometimes that is not always the case, sometimes the hardware or machinery that needs to be programmed might not support anything but those relics. For example, lets say you have a factory that produces 10,000 items per hour on a assembly line, and one of the controllers that this system relies on has embedded code written in the C language and to try and upgrade this one controller to meat modern standards would require that company to revamp the whole complex. The cost here for all new equipment isn't worth the investment. As I have said this is just a poor excuse by Microsoft.

  6. Against Copouts says:

    Part 2: During the days of when Win7 was first released, the download center was excellent where you could find anything that you needed to download, now it for the most part sucks for they now only have a few things here and there for windows 7, & 8 and mostly everything is geared towards Windows 10. Which is another dick move that Microsoft is now pushing onto its consumers. This whole blind move of installing GWX onto Windows 7 & 8 machines when the user has Automatically Download Important & Critical Updates, and the Recommended Updates box is checked as well, is nothing but a Spam – Spy – Ad – Malware nonsense. The original thought of Windows 10 free upgrade sounded promising, but instead of posting a link to download an ISO Image that a user can burn to disc and install at their readiness and convenience if they so choose would of been the best method to do it, instead they elected to constantly pop a message up in users faces like a flashing bulletin that you can not disable, that is extremely hard to remove and if the user clicked on it to check to see if they were eligible for the upgrade things even get worst! That's right worst, now when they go to use windows update it will download the upgrade to windows 10 through updates and try to install it and force the user into a system shutdown / restart for the upgrade installation to occur. This is not acceptable especially when it concerns the consumer and their rights! It is our Machines and we don't want it to upgrade automatically through windows updates at a time when "Microsoft" determines it should be installed. No, this is 100% Horseshit! People may have hardware devices that will not work with Windows 10 even if they are on a Windows 7 or 8 machine, and an installation as such can cause damage to files, devices and possibly even the machine entirely which would force the normal user to purchase a new machine. However, luckily I know how to build machines from the ground up, I just reinstalled Windows 7 and disabled the updates and elected to notify me, but I will choose which ones to download and which ones to install just to get rid of that annoying Trojan Virus called GWX.exe! This type of behavior and response to their customers is completely asinine and something of this nature is very quickly pushing me towards using Unix / Linux instead!

  7. Against Copouts says:

    Part 3: Another thing about this Automatic Upgrade through Windows Updates that is completely screwed up by Microsoft is the fact that having this done through Windows updates is a burden if the consumer either it be a home or small office had multiple machines where each machine tried to do this on its own. The bandwidth of data here would ramp up extremely fast and most of your internet providers including Comcast now have introduced Data Caps that if you go over a certain amount each month they will now charge you for it on top of already charging you to access or be connected to the internet which in itself is a dicked move. This is their way to exploit and extort their consumers by double charging them with the ability of not even call it so. [threats, foul language, and some continued ranting deleted]

  8. You are more than welcome to exercise your 'free speech rights' online, AC, but you can find any number of other more appropriate venues to host that content. Why not start your own blog?

    Technology evolves quickly, and at this point the original DirectX API came out 20 years ago. Windows 95 required 4 MBs of RAM, a single-threaded 386DX CPU running at 12 MHz, and 40 MB of disk space. A smart-watch has more computing power these days…

    As I've cataloged here and in other posts, the legacy DirectX SDK now mostly leads developers to use APIs that are no longer appropriate or have a known dead-end (such as not being supported for x64 native applications). The legacy DirectX SDK isn't even fully compatible with the C Runtime that is included for the VS 2015 toolset.

    It's not a 'copout' to clearly communicate that a particular technology is deprecated, provide ample time for developers to absorb the change–it has been over 5 years since the last DirectX SDK was released–, and develop replacements for scenarios which are still very much relevant.

    The C language remains extremely successful as a systems programming language, but for native application development including games C++ has long since become the defacto standard. C support for COM APIs like Direct3D is difficult to use, and is largely not worth the hassle.

Skip to main content