Not So Direct Setup

directx

Originally posted to Chuck Walbourn's Blog on MSDN, Sep 08, 2010

When the DirectX technology was created in the mid 1990s, it was designed to be deployed by games into the Windows 95 operating system as part of the game’s install process. As the number of supported operating systems grew, so did the complexities of deploying these components. The DirectSetup API and well-known DXSETUP.EXE program became common place on game disks, and PC gamers everywhere were trained to run it themselves to keep their systems ready for the latest games. Of course, there were also many problems with poorly written installers, misconfigured machines, and the fact that DirectX components themselves were rather invasive into the system.

IMPORTANT: The DirectX End-User Runtime has been updated in 2021 to address SHA-1 deprecation. Be sure to read this blog post and this one.

In 2004 when Microsoft released DirectX 9.0c, the test matrix was rather large. There was every Service Pack level of Windows 98, Windows 98 SE, Windows 2000, Windows Server 2000, Windows XP, and Windows Server 2003 plus all the variants to support. DirectSetup kept most of this detail hidden from developers and end-users, but it was a complicated job none-the-less. With the looming release of Windows x64, it looked like the test matrix was going to spiral out of control–at that point, only Windows 95 support has been retired.

The solution to this testing and deployment madness was simple: DirectX became part of the operating system. The components in DirectX 9.0c–Direct3D, DirectDraw, DirectSound, DirectInput, DirectMusic, DirectPlay, and DirectShow–were included with Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, and Windows XP x64 Edition (which is actually Windows Server 2003 SP1 in XP clothing). From that day forward, DirectSetup no longer deployed “DirectX” in the way that everyone had understood for a decade. DirectX 10 was released as part of Windows Vista and Windows Server 2008, with legacy components like Direct3D Retained Mode and DirectPlay Voice dropped due to security concerns and low levels of adoption. DirectX 10.1 was released as part of Windows Vista / Windows Server 2008 Service Pack 1. DirectX 11 is part of Windows 7 / Windows Server 2008 R2, and while it is available on Windows Vista / Windows Server 2008 this is done through Windows Update assuming you already have Service Pack 2 installed, not as a result of running DirectSetup.

In fact, the one thing that we can guarantee that DirectSetup doesn’t do anymore is “install DirectX”.

At the same time, there was a desire to continue to deliver game technologies like HLSL compiler, the D3DX DLL, XAudio2, XINPUT, XACT, etc. and these needed a way to be deployed to end-user systems. Since DirectSetup was already being included by every game, these DLLs were piggy-backed onto this already well-used deployment mechanism. Because modern versions of the OS included the DirectX components, most of the size of the DirectSetup REDIST was no longer relevant, and developers could just include the relevant .CABs for their product to minimize the size.

NOTE: For game developers looking to repackage older games, consider using the Microsoft.DXSDK.D3DX NuGet package which provides a side-by-side shippable version of D3DX9_43.DLL, D3DX10_43.DLL, D3DX11_43.DLL, and D3DCompiler_43.dll under a new license per this blog post. For XAudio2 on Windows 7 SP1 or later, consider updating your audio code using the Microsoft.XAudio2.Redist NuGet package as detailed on Microsoft Docs. These packages do not make use of legacy DirectSetup and are shipped ‘application local’.

For all the technical merits of this approach, it has had some long-term consequences. For one thing, developers needed to be told about the changes and what they should being doing for new games. Historic habits from the early days of DirectSetup still had developers reluctant to launch DXSETUP.EXE unless they felt they had to. Since the DirectX version number has basically nothing to do with running DirectSetup, guarding launch with it turned into a source of problems. Some developers didn’t understand that some of the DLLs (D3D9.DLL, etc.) they used were usually included in the OS, while others (D3DX9.DLL, etc.) were never included in the OS. Thus a slew of documentation, presentations, and samples to try to educate publishers and developers of this shift.

DirectX Installation for Game Developers

Direct3D 11 Deployment for Game Developers

Of course the problem with documentation is that not a lot of people actually read it. Furthermore, end-users trained to download every new release of “DirectX” were camping Microsoft Downloads for every release (despite zero use for their existing games), huge numbers of end-users still download the DirectX SDK and install it thinking it will help ‘fix’ their games, and of course game install developers tended to use exactly the same logic and tools that worked in the 1990s without really knowing why. End-user support forums are still full of posts from people who think that they need to install DirectX 9.0c on their Windows Vista or Windows 7 systems.

For game publishers, developers, and installation authors, the message today is quite different than it once was. You don’t actually deploy “DirectX” anymore. You pick a reasonable OS as your minimum bar and use the techniques I covered on version checking to ensure you always have 99% of what you need already included on the system. You then take a few of the DirectSetup files and CABs picked based on exactly what your game needs and always run it as part of your install process. Alternatively, you eliminate dependencies on all of these add-on ‘optional’ components.

For support websites, phone support, and end-users trying to help others in the community, running the latest DirectX End-User Runtime (stand-alone or websetup) is a reasonable way to work-around some poorly written game installations, but it is not a panacea. The best solution is to make sure you have the latest Service Pack and apply all pending Windows Updates. If you have an operating system older than Windows XP Service Pack 2, you should upgrade to something that is still supported by Microsoft. The only time running the DirectSetup package will help is if you are getting a message about missing D3DX*.DLL, D3DCompiler*.DLL (#43 or earlier), XAUDIO2*.DLL (2.7 or earlier), XINPUT*.DLL (1.1, 1.2, & 1.3), X3DAUDIO*.DLL, or XACTENGINE*.DLL (or the deprecated Managed DirectX 1.1 assemblies). That’s it.

The DirectX End-User Runtime (June 2010) does not include the .CAB files to deploy DirectX 9.0c onto Windows XP RTM or Windows XP SP1, although those are still available to DXWEBSETUP for historical purposes. The easier solution: require Windows XP Service Pack 2 or Service Pack 3 or later.

As of the June 2010, DirectX Web Setup and the DirectX End-User Runtime are no longer binary compatible with Windows 2000, Windows 98, or Windows ME. The February 2010 DirectX End-User Runtime will still work on Windows 2000, but it is worth noting that it doesn’t install much of anything on those systems: DirectX 9.0c and D3DX9*DLL are it. The June 2010 D3DX9 and later DLLs are not compatible with Windows 2000, and no other DirectX SDK optional component DLL (XAUDIO2, XINPUT, XACT, etc.) is supported on Windows 2000. The last release of the DirectX End-User Runtime to support Windows 98 or Windows ME was October 2006, and again that was only for DirectX 9.0c and D3DX9 up until October 2006 (no longer available). The December 2006 and later versions of D3DX9 are not compatible with Windows 98 or Windows ME, and no other DirectX SDK optional component DLL is supported on Windows 98 or Windows ME.

Windows 8, Windows 8.1, and Windows 10: For Win32 desktop games, the existing DirectSetup packages will work but will trigger the need to enable .NET 3.5 (which is off by default). Making use of the refreshed package will avoid this problem. For Windows Store apps (a.k.a. Metro style apps) on Windows 8.x or Windows RT, the DirectSetup package is not used.

Desktop Bridge applications: For these applications use of legacy DirectSetup to deploy these components is not an option. Ideally the application would be updated to remove all legacy DirectX SDK dependencies. If this is not possible there is a “DirectX Framework Package” available Microsoft.DirectX.x86 / Microsoft.DirectX.x64 which can be included for these packaged apps if they use D3DX9, D3DX10, D3DX11, XAudio 2.7, XInput 1.3, and/or XACT. There is no support for deploying legacy Managed DirectX 1.1 assemblies for Desktop Bridge applications.

Windows 8.0 SDK: The integrated DirectX SDK in the Windows SDK for Windows 8 does not make use of DirectSetup (See “Where is the DirectX SDK?”). The D3DCompiler_46.DLL and D3DCSX_46.DLL can be deployed with the application without using a redist package. XInput 1.4 and XAudio 2.8 are included with Windows 8 & Windows RT and later, and are not available down-level. The DirectX 11.1 runtime is included with Windows 8 & Windows RT, and some portions are available on Windows 7 Service Pack 1 via KB 2670838

Windows SDK for Windows 8.1: The integrated DirectX SDK in the Windows SDK for Windows 8.1 does not make use of DirectSetup (See “Where is the DirectX SDK (2013 Edition)?”). The D3DCompiler_47.DLL and D3DCSX_47.DLL can be deployed with the application without using a redist package. D3DCompiler_47.DLL is also included with Windows 8.1 and later. The DirectX 11.2 runtime is included with Windows 8.1.

Windows SDK for Windows 10: Again, it does not make use of DirectSetup (see “Where is the DirectX SDK (2015 Edition)?”). It is otherwise similar to the Windows SDK for Windows 8.1. The DirectX 11.3 and 12.0 runtime is include with Windows 10. DirectX 11.4 is also available with Windows 10 (November 2015, a.k.a. build 10586).

DirectPlay: Note that in Windows 8.1 and Windows 10, DirectPlay is not included by default but can be enabled as a Windows optional feature.

Games for Windows and the DirectX SDK blog