Using VS6 with DirectX April 2005 SDK

[Derek Smart [3000AD]]

Following in my tradition of beating an arguably dead horse and then cremating said horse, here is another one of my gems previously posted over here.

Enjoy!

Yeah, I know that there are still some dinosaurs out there, so I thought I'd share last nights late night gig as I previously did with the Summer 2004 SDK.

DISCLAIMER:


You should have upgraded from VS6 to .Net 2003 by now. I am only doing this excercise because of some legacy apps that I have. Also, VS 2005 is currently at Beta 2 and some of you on the fence may just want to wait until it rolls before moving on from VS6 because it is pointless moving to .Net 2003 now (if you haven't already) with VS 2005 so close to release. So, don't take this post as an endorsement to not upgrade from VS6.

First things first. Don't even think of trying to use the latest June 2005 SDK. It won't work. Trust me on this.

1. Download the April 2005 DirectX SDK (scroll down the page to the "Older SDK Releases" section
2. Download the April 2005 MS Platform SDK (scroll down the page and download PSDK-x86.exe)
3. Go to Keith's site and download the April or June DirectX 9.0c D3DX Only Installer Download
4. Assuming that you are using the Summer or October 2004 DirectX SDK, go to the
   Lib folder and copy the Dxerr9.lib and Dinput8.lib files to a temp folder.
5. Uninstall the current DirectX SDK.
6. Install the MS Platform SDK (assuming you don't already have the latest version installed)
7. Install the April 2005 DirectX SDK
8. Install the D3DX runtime files you downloaded from Keith's site
9. Reboot
10. Go to the Lib\x86\ folder where you installed the April 2005 SDK and backup the Dxerr9.lib and dinput8.lib files
11. Copy the Dxerr9.lib and dinput8.lib files from your previous Summer 2004 or October 2004 into the \Lib\x86 folder.
    
    In the case of the Dxerr9.lib file, the reason for this is that MS compiled that library (don't ask me why they did this with only this file) with buffer overrun/security checking (as they do with all their .Net libs now,
    hence the reason VS6 no longer works with DX) and any library function which makes calls to that library (e.g. to DXGetErrorString9) will cause linker errors
    e.g.
    

    Linking...
    dxerr9.lib(dxerr9.obj) : error LNK2001: unresolved external symbol ___security_cookie
    dxerr9.lib(dxerr9.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4

    
    In the case of the dinput8.lib file, you will get this error when compiling a debug app. For some unGodly reason, this file seems to contain corrupt and/or incorrect debugging information. So you will see something like this if you don't use the older version. Incidentally, when comparing these legacy files, in April 2005 SDK, MS decided to include versions that are older than those in the October 2004 Update. Don't ask.
    
    

    Linking...
    dinput8.lib(dilib2.obj) : fatal error LNK1103: debugging information corrupt; recompile module
    Error executing link.exe.

12. Start VS6 and go to Tools/Options/Directories. Make sure that the folder order is as indicated below. If any folder is not there, you need to add it. This is the order in which they need to appear.
    
    Include files:
    
    DirectX include folder
    MS Platform SDK include folder
    MS VC98 include folder
    MS VC98 MFC include folder
    MS VC98 ATL include folder
    
    Library files:
    
    DirectX lib folder
    MS VC98 lib folder
    MS VC98 MFC lib folder

Couple of things to note:

1. Keith states on his site that the April 2005 SDK works with VS6; which is why I decided to try it for this legacy app which I still had using the October 2004 SDK. I've sent him email letting him know that it doesn't quite work without the tinkering indicated above.
2. DirectShow is now in the MS Platform SDK. If you had modules which were based off any of its samples, you will have to modify them to work. e.g. this legacy app I was trying to build, was using an AVI player based on the original cutscene.cpp sample program included with DirectShow. Now that file has been moved into the \Microsoft Platform SDK\Samples\Multimedia\DirectShow\Players\Cutscene folder. It has been modified to work with later DX and MS PSDK builds, so your legacy app won't work without revision. e.g. you will get linker errors like lstrcpy_instead_use_StringCbCopy_or_StringCchCopy or wsprintf_instead_use_StringCbPrintf_or_StringCchPrintf etc because the older versions of some DirectShow samples, did stuff like:
   
   

   wsprintf(szTitle, TEXT("%s: \0"), CUTSCENE_NAME);
    _vsntprintf(szBuffer, NUMCHARS - 1, szFormat, pArgs);

   
   which have now been changed to:
   
   

   (void)StringCchPrintf(szTitle, NUMELMS(szTitle), TEXT("%s: \0"), CUTSCENE_NAME);
   (void)StringCchVPrintf(szBuffer, NUMCHARS - 1, szFormat, pArgs);

   
   You will have to revise your DirectShow sources to match the changes in the new samples in order to get them to work. Thats what I had to do with that one DirectShow sample (cutscene.cpp) that my player was based on.
3. If you have been compiling a DX8.1 based source app with the DX9 SDK, they will no longer compile without further tinkering. e.g. the d3dx8.h file is gone. And no, replacing all calls to that header file with d3dx9.h won't work without further significant tinkering. You will have to port the app to DirectX9 SDK. Good luck with that if you didn't do it before. If someone knows a way around this and which I may not be aware of, please let me know.