Sign in to follow this  
ProgrammerDX

d3dx9_42.dll

Recommended Posts

Hello,

I was wondering why my application requires this .dll ? All my users can not run my program because this dll is missing on their PC's.. Cant I build my program so this dll is not required? Since only persons who have DirectX SDK installed can run my program otherwise...

My program includes d3d9.dll too but that doesnt give an error.. so its not like they dont have DirectX9 installed.

Thanks

Share this post


Link to post
Share on other sites
Your program requires a more recent DirectX Version than what your users have installed. There often new revisions of DirectX 9 (and 10,11) so people need to keep their DirectX up to date. The solution is the bundle your software with a recent DirectX redistributable (or DirectX web redistributable).
While you CAN bundle d3dx9_42.dll (search for it on your System, if you use 64-bit, use the one in your SysWow64 directory) into your executable directory, this is a violation of the DirectX license agreement, which requires you to use the DirectX redistributable. Did you never notice Games bundling DirectX with their installers? That's what you need to do.

Share this post


Link to post
Share on other sites
You must redistribute the DLL for the Direct3D version you're using.

This DLL is usually installed into the end-user's C:\WINDOWS\System32 directory. Include the DLL with your application's installer if you currently have one, else just provide instructions for your end-users to put the DLL into the system32 directory.

You can find the DLL in the similarly named CAB file in the "Redist" subdirectory of your SDK directory (that one should start with Aug2009 if I'm not mistaken).

EDIT: @vectrexx: Thanks, I didn't actually know that little licensing bit. That's probably a good thing to know.

Share this post


Link to post
Share on other sites
On the flip side, many programs DO bundle only the required DLLs and especially for a small program it's ridiculous to pack the whole 100MB DirectX redistributable, and using the Web redist can also annoy users. I haven't heard of anybody getting into trouble yet, so that's probably something to research.

Share this post


Link to post
Share on other sites
I wouldn't say "most" programs do that. According to the license agreement, you're supposed to use the redistributable.
EDIT: I have looked into and it seems you can strip unnessecary files from the redistributable package:
http://msdn.microsoft.com/en-us/library/ee416805%28VS.85%29.aspx
So that's what you should do.

Share this post


Link to post
Share on other sites
[quote]Original post by vectrexx
it's ridiculous to pack the whole 100MB DirectX redistributable,/quote]

You can strip down DirectX installation to only required parts (dll's). This way you can get down to few MB's: http://msdn.microsoft.com/en-us/library/ee416805.aspx#ID4EYF

Share this post


Link to post
Share on other sites
Alternatively you can either dynamically link to D3DX (using LoadLibrary and GetProcAddress) or compile your program against an earlier version of the SDK (versions from as far back as 2004 are still available on the MS website). Both options should work fine and will avoid the downsides of having to deal with licensing doubts and of requiring users to update their DirectX.

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgrammerDX
Can't I just add d3dx9_42.dll to my installation like most programs do?
No - not only is it a violation of the EULA, it's also a security concern.

The reason the D3DX library was moved into a DLL was so that it can be patched via Windows Update, in case a security problem is found. If you always overwrite the version on the user's machine with your version, then you might be overwriting a newer, patched version of the DLL with a broken version. Like wise, if you put the DLL in your application's working directory, then the OS will load that one instead of the potentially patched one.

Quote:
Original post by mhagain
Alternatively you can either dynamically link to D3DX (using LoadLibrary and GetProcAddress)
The fact that the OP gets an error about the DLL missing implies that they're using D3DX functions - so loading the DLL at runtime wouldn't really help - it'd just allow him to display a "nicer" message to users. However, delay loading is a better solution, since it means you don't need to manually call GetProcAddress() for every function used, and still lets you display a user friendly error.

Quote:
Original post by mhagain
...or compile your program against an earlier version of the SDK (versions from as far back as 2004 are still available on the MS website)
I'd recommend against this; newer versions of the D3DX library have several performance and security improvements over older versions.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil SteveNo - not only is it a violation of the EULA, it's also a security concern.

The reason the D3DX library was moved into a DLL was so that it can be patched via Windows Update, in case a security problem is found. If you always overwrite the version on the user's machine with your version, then you might be overwriting a newer, patched version of the DLL with a broken version. Like wise, if you put the DLL in your application's working directory, then the OS will load that one instead of the potentially patched one.


Though if he included his own DLLs, he'd be pretty unlikely to install them in the system folder, adding a D3DX DLL in your application folder has no effect on the rest of the system, merely prevents him from taking advantage of future updates to the dll.

Share this post


Link to post
Share on other sites
Quote:
Original post by marius1930
Though if he included his own DLLs, he'd be pretty unlikely to install them in the system folder, adding a D3DX DLL in your application folder has no effect on the rest of the system, merely prevents him from taking advantage of future updates to the dll.
The application's working directory takes precedence over the system32 directory, so the DLL included with his app would be used instead of the potentially patched one in system32.

EDIT: MSDN: Dynamic-Link Library Search Order

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Quote:
Original post by marius1930
Though if he included his own DLLs, he'd be pretty unlikely to install them in the system folder, adding a D3DX DLL in your application folder has no effect on the rest of the system, merely prevents him from taking advantage of future updates to the dll.
The application's working directory takes precedence over the system32 directory, so the DLL included with his app would be used instead of the potentially patched one in system32.

EDIT: MSDN: Dynamic-Link Library Search Order


Thats what i just said. it prevents HIM from taking advantage of any updates, but does not affect the rest of the system. As opposed to "overwrite the version on the user's machine with your version", which seems like an unlikely scenario. (placing it in system)

Share this post


Link to post
Share on other sites
Quote:
Original post by marius1930
Thats what i just said. it prevents HIM from taking advantage of any updates, but does not affect the rest of the system. As opposed to "overwrite the version on the user's machine with your version", which seems like an unlikely scenario. (placing it in system)
Oh - whoops, I misread it.
It's still not really a good idea though, it just takes one application with a security problem to cause trouble.

Share this post


Link to post
Share on other sites
I've detected in old games that the D3DX helper functions are embedded into the executable of the game itself and the D3DX functions are not in a seperate DLL.

That's way better, and also makes it more annoying for cheat programmers to hook those DLL functions.

Is it just security so Windows can update the DLL that the D3DX functions are placed in a DLL?

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgrammerDX
I've detected in old games that the D3DX helper functions are embedded into the executable of the game itself and the D3DX functions are not in a seperate DLL.

That's way better, and also makes it more annoying for cheat programmers to hook those DLL functions.

Is it just security so Windows can update the DLL that the D3DX functions are placed in a DLL?
The D3DX library uses to be a static library before December 2004 (I think it was Dec 2004). That was a problem for the security reasons already mentioned, and it means that a simple program that uses D3DX was usually over 1MB in size because of the static library.

You already need to distribute the Visual Studio runtime with your app, it's not much more work to distribute a stripped down DirectX runtime too.

Share this post


Link to post
Share on other sites
I'm not using CRT or ATL or MFC in my code, so I dont need to include the Visual Studio runtime.

Anyway I did some investigation, installng the redist is pretty simple on a client machine.

Just with using dxsetup.exe

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgrammerDX
I'm not using CRT or ATL or MFC in my code, so I dont need to include the Visual Studio runtime.

Anyway I did some investigation, installng the redist is pretty simple on a client machine.

Just with using dxsetup.exe
If you're using main() or WinMain() then you're using the CRT.

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgrammerDX
Ok but that doesn't need a redistributable package
Yes it does. The CRT is the C Runtime Library, which contains all the implementation of functions like strlen, malloc, localtime, printf, and so on. If you're using main or WinMain in your app, then your applications entry point is mainCRTStartup() or winmainCRTStartup(). Those functions set up various CRT state, such as initialising the heap so malloc and new can function, and then call main() or WinMain() - and those functions require the CRT to use.
You can put a breakpoint on the first line of main() / WinMain() and then look at the call stack and you'll see that the previous function in the stack is the CRT startup function.

Without using the CRT, you can't use any C functions, only functions exposed by kernel32.dll. So you'd need to use VirtualAlloc to allocate a chunk of memory and then implement new to use that chunk of memory instead of delegating to malloc as the default does.

The reason you might not think you need the VC redist package, is that a lot of other applications are written using Visual Studio, and one of them has probably installed the runtime libraries you need - but you can't rely on it.

Share this post


Link to post
Share on other sites
Quote:
Original post by ProgrammerDX
CRT is a static library, atleast with Visual Studio, no linking with a DLL at all
By default, Visual Studio 2005 onwards (Possibly VC2003, I'm not sure) will link to the DLL version of the CRT. You can always change that to the static library in your linker settings though, yes.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this