Skip to main content
GameDev.net gamedev.net
🔒 Locked

Using VS6 with DirectX April 2005 SDK

Started by dsmart Jun 27, 2005 at 6:51 AM 4 replies 18.4k views
Original Post
dsmart
dsmart
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 by now!!!! I am only doing this excercise because of some legacy apps that I have. Also, VS2005 has already been released and it is tons better than VS6. 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. :) *NOTE: I have been told that installing the August 2006 SDK and using just the libs (not the includes) from the October 2005 and April 2005 SDKs, also seems to work as well.
  1. Download the April 2005 DirectX SDK
  2. Download the Windows® Server 2003 R2 Platform SDK
  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, Dinput8.lib files to a temp folder. NOTE: You may also want dinput.lib. To be sure, copy it to another folder. Then once you have got everything going with those two files, if you have problems ONLY then should you copy this older dinput.lib file over the current version.
  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, dinput8.lib and dinput.lib files
  11. Copy the Dxerr9.lib, dinput8.lib and dinput.lib files from your previous Summer 2004 or October 2004 into the \Lib\x86 folder. When you're done, your [hacked] DirectX April 2005 SDK include and lib\x86 file listings should look something like this.
    
    d3d.h           88071   9/27/04  11:34 
    d3d8.h          72232   9/27/04  11:34 
    d3d8caps.h      16088   9/27/04  11:34 
    d3d8types.h     63735   9/27/04  11:34 
    d3d9.h         100838   9/28/04  22:59 
    d3d9caps.h      22164   9/28/04  22:59 
    d3d9types.h     72337   9/28/04  22:59 
    d3dcaps.h       26113   9/27/04  11:34 
    d3drm.h         14874   9/27/04  11:34 
    d3drmdef.h      24261   9/27/04  11:34 
    d3drmobj.h      79538   9/27/04  11:34 
    d3drmwin.h       1174   9/27/04  11:34 
    d3dtypes.h      79922   9/27/04  11:34 
    d3dvec.inl       5476   9/27/04  11:34 
    d3dx9.h          1933   3/18/05  16:26 
    d3dx9anim.h     43369   3/18/05  16:26 
    d3dx9core.h     23722   3/18/05  16:26 
    d3dx9effect    42007   3/18/05  16:26 
    d3dx9math.h     58152   3/18/05  16:26 
    d3dx9math.i    45124   3/18/05  16:26 
    d3dx9mesh.h    117735   3/18/05  16:26 
    d3dx9shader    41634   3/18/05  16:26 
    d3dx9shape.h     7943   3/18/05  16:26 
    d3dx9tex.h      61167   3/18/05  16:26 
    d3dx9xof.h      12012   3/18/05  16:26 
    ddraw.h        245282   9/27/04  11:34 
    dinput.h       227611   9/27/04  11:29 
    dinputd.h       32944   9/27/04  11:29 
    dls1.h           9302   9/27/04  11:34 
    dls2.h           4855   9/27/04  11:34 
    dmdls.h          7538   9/27/04  11:34 
    dmerror.h       27296   9/27/04  11:34 
    dmksctrl.h       5329   9/27/04  11:34 
    dmplugin.h      16407   9/27/04  11:34 
    dmusbuff.h       1778   9/27/04  11:34 
    dmusicc.h       36117  11/16/04  14:34 
    dmusicf.h       75208  11/16/04  14:34 
    dmusici.h      108022  11/16/04  14:34 
    dmusics.h        9659   9/27/04  11:34 
    dpaddr.h        16366   9/27/04  11:34 
    dplay.h         87455   9/27/04  11:34 
    dplay8.h        70639   9/27/04  11:34 
    dplobby.h       30014   9/27/04  11:34 
    dplobby8.h      18996   9/27/04  11:34 
    dpnathlp.h      13754   9/27/04  11:34 
    dsconf.h         9831   9/27/04  11:34 
    dsetup.h         8889   9/27/04  11:34 
    dsound.h       110107   9/27/04  11:34 
    dvoice.h        34824   9/27/04  11:34 
    dvp.h           32952   9/28/04  22:59 
    dx7todx8.h       5615   9/27/04  11:43 
    dxdiag.h         8142   3/16/05  10:22 
    dxerr8.h         2919   3/16/05  10:22 
    dxerr9.h         2968   3/16/05  10:22 
    dxfile.h         8155   9/27/04  11:43 
    dxsdkver.h        488   3/18/05  16:26 
    dxtrans.h      158905   9/27/04  23:18 
    multimon.h      15154   9/27/04  11:34 
    PIXPlugin.h      5918   3/18/05  16:26 
    rmxfguid.h       8751   9/27/04  11:34 
    rmxftmpl.h      17623   9/27/04  11:34 
    strsafe.h      221230   4/01/04  16:42 
    
    
    
    
    d3d8.lib         2704   9/03/04  15:18 
    d3d9.lib         5226   9/03/04  15:18 
    d3dx9.lib       86070   3/18/05  16:37 
    d3dx9d.lib      86400   3/18/05  16:06 
    d3dxof.lib       1746   9/29/04  16:47 
    ddraw.lib        4540   9/06/04  20:58 
    dinput.lib     161464   9/03/04  15:18 
    dinput8.lib     19978   9/27/04  12:29 
    dplayx.lib       3142   9/03/04  15:18 
    dsetup.lib       5998   9/27/04  11:34 
    dsound.lib       4042   9/03/04  15:18 
    DxErr8.lib    1083206   3/18/05  16:39 
    Dxerr9.lib    3901404   9/29/04   1:15 
    dxguid.lib     121084   3/18/05  16:39 
    dxtrans.lib      3700   9/03/04  15:18 
    
    
    
    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\x86 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.
[Edited by - dsmart on September 6, 2006 3:49:58 PM]
"Game developers are just human beings who happen to make games for a living.
If you want to hold us up to higher standards of conduct, then go ahead
...but don't be surprised if we don't uphold them."
jollyjeffers
jollyjeffers
Good bit of detective work! Admittedly, not much use to me as I develop with VC7 [smile]

You might well want to PM Coder to see if he wants to put this in the Forum FAQ alongside the other information about DX/VC++6... As you say, people should be using a better compiler, but this question still gets asked every now-and-then..

Cheers,
Jack
<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ |
circlesoft
circlesoft
Aye, nice job [smile] It's good to see they finally put the DShow stuff back into the platform SDK.

Quote:
but this question still gets asked every now-and-then..

Remember back in December when it was getting asked like twice a day? [oh] It was like we were in a war against the VC6 users hehe
jollyjeffers
jollyjeffers
Quote:
Original post by circlesoft
Quote:
but this question still gets asked every now-and-then..

Remember back in December when it was getting asked like twice a day? [oh] It was like we were in a war against the VC6 users hehe

I guess that because we're still here, and those regular questions aren't that we won [grin]

Jack
<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ |
dsmart
dsmart
Quote:
Original post by jollyjeffers
Quote:
Original post by circlesoft
Quote:
but this question still gets asked every now-and-then..

Remember back in December when it was getting asked like twice a day? [oh] It was like we were in a war against the VC6 users hehe

I guess that because we're still here, and those regular questions aren't that we won [grin]

Jack


...either that or they gave up and embraced OpenGL and GCC [grin]
"Game developers are just human beings who happen to make games for a living.
If you want to hold us up to higher standards of conduct, then go ahead
...but don't be surprised if we don't uphold them."
dsmart
dsmart
It occured to me that I should add an addendum to my post for those stuck in VS6.

There is no reason to stick with VS6 unless you are resistant to change and don't want to give yourself more work.

You can get VS7 in .Net 2003 for free. While it is just a commandline compiler, you can get an excellent open source IDE for it.

Here is what you do.


  1. Download the Microsoft's Visual C++ Free Toolkit 2003
  2. Download the open source Code::Blocks IDE
  3. Install the 2003 Toolkit
  4. Install Code::Blocks. When you first run it, it will auto-detect the 2003 toolkit.
  5. Open up the Code::Blocks FAQ in your browser and follow the instructions to set everything up.
  6. If you have existing project (.dsp) and workspace (.dsw), these can be automatically imported to the Code::Blocks format as-is. You don't have to change a thing!


The Code::Blocks IDE is fully functional, extensible and it just works. No bloat.

Now, if you are porting over a C/C++ hybrid app, you're going to run into some problems. Trust me, the first time you build your project, you're going to be crapping bricks when you see how many warnings and errors VS7 is going to spew out.

e.g. is now . And no, even if you go in and change your source files and headers, that won't fix the problem because the stream functions are different.

You also don't have the benefit of the F1 help system you have come to know and love in VS6. Then again, you get what you pay for, right?

So, you will run into stuff like that. If you don't want to do the work involved with moving into the current gen, stick with VS6.

And oh, using the 2003 Toolkit means you don't have to keep hacking DirectX SDK to make it work. :grin:

You could also grab the Visual Studio 2005 Beta2 download. Its free and if you are in North America, MS will even send you the CD-ROM for free. It is time limited though and you should only consider getting this IF you think that you will finally be abandoning VS6 within the next 2-3 month. You can also try the Visual Studio Express Beta products; but these are not as hardcore and advanced as the full blown VS.

Hope this helps someone out there just dying to stop doing the DirectX SDK song and dance with each new release.
"Game developers are just human beings who happen to make games for a living.
If you want to hold us up to higher standards of conduct, then go ahead
...but don't be surprised if we don't uphold them."

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.