Getting VS2013, DirectXMath, XAudio2 and D3D11 to work together targetting Windows 7

Question

Working on upgrading my product to new compiler version and new technologies, but Microsoft seem to have made a mess of this...

• The version of XAudio2 that comes with VS2013/WinSDK will not work on Windows 7, and there is no compile flag to fix that (have _WIN32_WINNT on a pre-8 value it wont even include, set it higher and its link library looks for a newer DLL name anyway).
• The other existing DirectX components, such as D3D11 seem fine when used with their Win8 SDK headers and import libs. Win7 users still need to have installed the DirectX SDK versions of d3d11.dll etc.
• Attempting to put the DirectX June 2010 SDK in the include path (to get a version of XAudio2 that will work), results in macro conflicts, eg between dxgitype.h and winerror.h. It seems Microsoft moved a large number macros into winerror.h, and there is no preprocessor check before attempting to define them...
• The DirectXMath headers appears to only be in the Windows8 SDK headers, they have no issue with the Windows 7 _WIN32_WINNT=0x0601, but this fact prevents me going to an older SDK without the winerror.h crap...

I am wondering if I can hack it by undefing _WIN32_WINNT to include the Win8 XAudio2 then cloning the DirectX SDK versions inline COM wrappers, but that leaves me exposed if any of the XAudio2 public interfaces actually changed (eg structure layouts or new members).

There must be a proper way to do this... If I can make it on Win8 systems use the OS provided DLL rather than the old DX redist one in a safe manner (and without compiling my code twice, I really want to avoid a separate win8 32/64 desktop exe on top of all the others) that would even better.

Answer 1

OK found a C/C++ include resolution hack/workaround that appears on initial testing to work. If anyone has a proper solution Id love that

1. Generally when people install the DirectX SDK, their Visual Studio will end up with $(DXSDK_DIR) even if its not by default on the include path, but like I said, just putting it first does not work, so...
2. Define a preprocessor macro to equal "$(DXSDK_DIR)Include\\xaudio2.h" in the project settings.
3. Include that macro to get the DXSDK version of xaudio2.h regardless of the include path. This took some fun since even with the full path I couldn't get MSVC to provide a quoted value (it appeared to strip quotes around it in project settings...).
4. Now it complains about "#include <comdecl.h>", apparently that isnt in the Window's SDK and because XAudio2 used <> it wont get picked up in the directory. So add the DXSDK_DIR\\Include to your include path anyway, after the Windows SDK .
5. By some miracle whatever is in comdecl.h does not conflict with anything (that I have included at least), and this compiled and linked cleanly, and ran as expected on a Window's 7 system (not tested on Windows 8, and certainly not tested yet if I can make it load the Win8 version of the XAudio DLL's with my own LoadLibrary/etc code path)

Including the macro

#define INCLUDE_XAUDIO2_EXPAND(path) <path>
#include INCLUDE_XAUDIO2_EXPAND(INCLUDE_XAUDIO2)

EDIT: This also appears to break the IDE error detection and auto-completion, it seems to not be able to process that include...