D3DX9_24.dll
Author
I am sure I am not the first person to have this problem, but wondered if there was a yet a known solution for it. I am writing my program using the Feb 2005 release of the DirectX SDK, but other people cant run it becuase 'd3dx9_24.dll' is missing from their systems, even though the latest available version (9.0c) of DirectX is installed.
It is possible to obtain this single missing dll from the web, but Microsoft prohibits distribution of it, and its also a hassle as it has to be manually placed in the correct directory.
Microsoft's solution is to distribute the DirectX redistributable with your program, but this is over 30 megs, and my program is just over 1 meg, so seems a bit ridiculous.
Just wondered if anyone else has encountered or solved this problem.
Cheers,
Ols
Quote:Original post by ols
I am sure I am not the first person to have this problem, but wondered if there was a yet a known solution for it. I am writing my program using the Feb 2005 release of the DirectX SDK, but other people cant run it becuase 'd3dx9_24.dll' is missing from their systems, even though the latest available version (9.0c) of DirectX is installed.
It is possible to obtain this single missing dll from the web, but Microsoft prohibits distribution of it, and its also a hassle as it has to be manually placed in the correct directory.
Microsoft's solution is to distribute the DirectX redistributable with your program, but this is over 30 megs, and my program is just over 1 meg, so seems a bit ridiculous.
Just wondered if anyone else has encountered or solved this problem.
Cheers,
Ols
The latest SDK( april 2005) uses a DLL for D3DX functions, while previous versions of the SDK used a static library for D3DX, so you are probably one of the first find this problem.
I agree that if the only way to redistribute this DLL(legally) is with all the other DirectX redistributibles this is a real drag, especially as the SDK gets updated every couple of months these days.
Search Google newsgroup archives on "DirectX" and "DLL hell" to find other people have the same concerns.
*** edit ***
Feb version too?
With you,
Cambo_frog
I just recently ran into this same problem. I used this latest SDK to create a small Demo (about 250K). I have been simply including this DLL in my download. It may not be strictly legal but this is just a simple demo application ... I am not selling anything, and I want to keep it as small as possible. I'll check at the Microsoft web site to see if any more information is available.
Quote:Original post by PaulHig
I just recently ran into this same problem. I used this latest SDK to create a small Demo (about 250K). I have been simply including this DLL in my download. It may not be strictly legal but this is just a simple demo application ... I am not selling anything, and I want to keep it as small as possible. I'll check at the Microsoft web site to see if any more information is available.
I have a feeling a lot of people may do the same :)
Cambo_frog
Not that it helps *right now* but I did hear the MS team is working on a solution for this very problem.
I'm experiencing the same thing myself, moving code back and forth between dev machines (one with the Feb2005 SDK and one with the new April2005 SDK) and it's a bit annoying.
Is it possible to link to the static version of the D3DX library, or do we forever have this new round of "DLL Hell" with differing versions of the D3DX Dll?
I guess it's time to crack open the header files to see if there's any #define's to take advantage of here..
I'm experiencing the same thing myself, moving code back and forth between dev machines (one with the Feb2005 SDK and one with the new April2005 SDK) and it's a bit annoying.
Is it possible to link to the static version of the D3DX library, or do we forever have this new round of "DLL Hell" with differing versions of the D3DX Dll?
I guess it's time to crack open the header files to see if there's any #define's to take advantage of here..
Quote:Original post by jollyjeffers
I'll see if I can find a link to it, but theres been some fairly harsh words said on the DIRECTXDEV mailing list about it - and the DirectX team have been quite open in accepting that it's completely f***ed up [smile]
Jack
Well, I'm not sure I'd characterize our response that way. [smile]
The main issue at hand is that moving d3dx to a dll has exposed some holes in our "always ship the redist with your application" recommendation. We are working on plugging those holes, but we're doing so based on discussions and feedback from developers. The Apr05 SDK update has the first step toward that goal -- developers can customize the redist to remove some components they don't require for their application. The remaining problem is that developers can't remove the main xp 9.0c bits. We're working on that but making that kind of change takes time to test and verify - we like doing that.
Paul Bleisch
WGGT Solutions
Quote:Original post by jollyjeffers
From my reading-between-the-lines of their replies, it sounds like a requirement imposed by top level Microsoft management.
Quote:
You can easily see why management-types would love the idea [grin]. It's just us developers that get punched in the face at the end of the day...
Yup, this says it all really.
Management getting involved in decisons they don't undersand the consequences of.I have seen it all before as I am sure many others have ...sigh
--
Cambo_frog
Poor Paul...damned if you do, damned if you don't.
The world cries out for tougher security measures from MS, then we turn around and bitch when things go the other way..:)
Paul, I guess with this track "chosen" by the DirectX team, I guess it's too late to include both a static and dynamic version to link to with each SDK update. *grin*
But is there a way to lockdown which version of the D3DX DLL you're compiling to in your application (besides only using the header files from a particular SDK version..ie. Dec. 2004 or Feb. 2005 whatever).
Can I #define a specific D3DX Version??
ie. #define USE_D3DX9_24
Just a thought...thanks for your patience with us.
The world cries out for tougher security measures from MS, then we turn around and bitch when things go the other way..:)
Paul, I guess with this track "chosen" by the DirectX team, I guess it's too late to include both a static and dynamic version to link to with each SDK update. *grin*
But is there a way to lockdown which version of the D3DX DLL you're compiling to in your application (besides only using the header files from a particular SDK version..ie. Dec. 2004 or Feb. 2005 whatever).
Can I #define a specific D3DX Version??
ie. #define USE_D3DX9_24
Just a thought...thanks for your patience with us.
Quote:Original post by wazoo69
Poor Paul...damned if you do, damned if you don't.
The world cries out for tougher security measures from MS, then we turn around and bitch when things go the other way..:)
Paul, I guess with this track "chosen" by the DirectX team, I guess it's too late to include both a static and dynamic version to link to with each SDK update. *grin*
But is there a way to lockdown which version of the D3DX DLL you're compiling to in your application (besides only using the header files from a particular SDK version..ie. Dec. 2004 or Feb. 2005 whatever).
Can I #define a specific D3DX Version??
ie. #define USE_D3DX9_24
Just a thought...thanks for your patience with us.
The version of the DLL required by your app is determined when you link your app. For example, d3dx9_24.dll is the Feb05 version of the dll, the only way your app will require that dll is if you build your app against the d3dx9.lib that is included in the Feb05 sdk. The Apr05 version is _25, the June one may or may not be _26 (new sdk release does not necessarily mean new dll release). The assumption we're making right now is that ISVs ship the dx redist that came with the SDK that their app was built against. If one needs to ship multiple exes that link to different versions of d3dx (i.e. a.exe needs d3dx9_24.dll and b.exe needs d3dx9_25.dll), you can make that work too (see docs).
So, in short, you choose which dll you want/need by choosing which SDK you link to.
For now, the solution is to use the December SDK, which doesn't require a DLL for D3DX.
Microsoft claims they are working on a better solution; possibly a downloadable installer that's a few hundred k which would download and update whatever components necessary on the user's machine.
Microsoft claims they are working on a better solution; possibly a downloadable installer that's a few hundred k which would download and update whatever components necessary on the user's machine.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
