I was setting up my JDK 7 build environment on Windows 7, and since I have
been using that Windows 7 system mainly for FX development it had on it
the DX 9 Nov 2007 SDK mandated by a different product. JDK requires DX 9 Summer 2004
but I didn't really think about it much, since I figured I should be able to use the
newer one.

However it turns out there's a conflict. I also happen to be using VS2010 and
its accompanying Windows 7.0a SDK, and that may be a part of the problem.
I get the following error :-

============================================
C:/vs2010/Common7/Tools/../../Vc/Bin/cl -Od -Zi -nologo -MD /D _STATIC_CPPLIB -Zc:wchar_t- -Fdc:/jdk7bld-fastdebug/tmp/sun/javax.sound/jsoundds/obj_gO/PLATFORM_API_WinOS_DirectSound.pdb -Fmc:/jdk7bld-fastdebug/tmp/sun/javax.sound/jsoundds/obj_gO/PLATFORM_API_WinOS_DirectSound.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -DDEBUG -DLOGGING -DWIN32 -DIAL -D_LITTLE_ENDIAN -D_X86_ -Dx86 -DWIN32_LEAN_AND_MEAN -I. -Ic:/jdk7bld-fastdebug/tmp/sun/javax.sound/jsoundds/CClassHeaders -I../../../../src/windows/javavm/export -I../../../../src/share/javavm/export -I../../../../src/share/native/common -I../../../../src/windows/native/common -I../../../../src/share/native/javax/sound -I../../../../src/windows/native/javax/sound -DX_PLATFORM=X_WINDOWS -DX_ARCH=X_I586 -DUSE_DAUDIO=TRUE -I../../../../src/share/native/com/sun/media/sound -IC:/tools/DXSDKN~1/include -c -Foc:/jdk7bld-fastdebug/tmp/sun/javax.sound/jsoundds/obj_gO/PLATFORM_API_WinOS_DirectSound.obj ../../../../src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp
PLATFORM_API_WinOS_DirectSound.cpp
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objidl.h(11280) : error C2061: syntax error : identifier '__RPC__out_xcount_part'
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objidl.h(11281) : error C2059: syntax error : ')'
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objidl.h(11281) : fatal error C1903: unable to recover from previous error(s); stopping compilation
make381[6]: *** [c:/jdk7bld-fastdebug/tmp/sun/javax.sound/jsoundds/obj_gO/PLATFORM_API_WinOS_DirectSound.obj] Error 2
make381[6]: Leaving directory `/cygdrive/c/jdk7src/jdk/make/javax/sound/jsoundds'
make381[5]: *** [build] Error 1
make381[5]: Leaving directory `/cygdrive/c/jdk7src/jdk/make/javax/sound'
make381[4]: *** [all] Error 1
make381[4]: Leaving directory `/cygdrive/c/jdk7src/jdk/make/javax'
make381[3]: *** [all] Error 1
make381[3]: Leaving directory `/cygdrive/c/jdk7src/jdk/make'
make381[2]: *** [jdk-build] Error 2
make381[2]: Leaving directory `/cygdrive/c/jdk7src'
make381[1]: *** [generic_debug_build] Error 2
make381[1]: Leaving directory `/cygdrive/c/jdk7src'
make381: *** [build_fastdebug_image] Error 2

========================================

A bit of google searching lead me to this thread and advice

http://social.msdn.microsoft.com/Forums/en-US/windowssdk/thread/a47e4fe8-7b3f-45fc-83ee-6bd225213eb9
"I think I know what might be causing this problem. If the DirectX SDK was installed after the Windows SDK,
the DirectX \include directory will come before the Windows SDK \include directory in your PATH.
This means that Visual Studio will be build with the version of objidl.h that ships in the DirectX SDK.
You must build with the version of objidl.h that ships in the Windows 7 SDK."

Since we set up all our INCLUDE paths pretty much explicitly I wasn't sure if that exact advice
should apply
I was also puzzled me since I had already built a number of times on Windows XP .. why was I only now
getting this error? That's when I remembered the DX SDK I was using is not the JDK mandated one.
I just installed the correct 2004 one and it looks like that magically fixes the compilation of at least
this one file.

All of the DX 9 2004 2007 SDKs and the Windows 7.0a SDK all include a "dsound.h" and
presumably some other files that get included too.

I wonder if its even what we want for the sound build to use the DX9 version of this file ?
Maybe once we use the Windows 7 SDK we should use its jsound.h ? Or may be
that's not correct ... I really don't know. But at least we should make sure
the header files we intend to use are the ones being used.