   How DXUT creates the IDirect3D9 object...
  HiI guess a short code sample is better than a thousand explanations:// This may fail if DirectX 9 isn't installedWCHAR wszPath[MAX_PATH+1];if( !::GetSystemDirectory( wszPath, MAX_PATH+1 ) )    return false;StringCchCat( wszPath, MAX_PATH, L"\\d3d9.dll" );s_hModD3D9 = LoadLibrary( wszPath );s_DynamicDirect3DCreate9 = (LPDIRECT3DCREATE9)GetProcAddress( s_hModD3D9, "Direct3DCreate9" );IDirect3D9 * pD3D = s_DynamicDirect3DCreate9(SDKVersion);(I stripped out irrelevant parts)So basically the path ends up being c:\windows\system32\d3d9.dllIs it safe to assume that the runtime are always in the system32 folder ?On the one hand I find that approach rather strange compared to the classical approach of calling Direct3DCreate9 directly.On the other hand, I assume Microsoft code writers are not plain morons and quite more qualified than I am (which is euphemistic)Correct me if I'm wrong, but that approach allows you to detect if the d3d9.dll is missing (I stripped out the error checking) at run time and popup an appropriate error message to the user. But comparing the returned value of Direct3DCreate9() could allow me to do almost the same, so what do you think ?   
Quote:Original post by janta(I stripped out irrelevant parts)So basically the path ends up being c:\windows\system32\d3d9.dllIs it safe to assume that the runtime are always in the system32 folder ?No, it's not safe. On my 64-bit system (and others), the 32-bit d3d9.dll will be in System\SysWow64.Quote:Correct me if I'm wrong, but that approach allows you to detect if the d3d9.dll is missing (I stripped out the error checking) at run time and popup an appropriate error message to the user. But comparing the returned value of Direct3DCreate9() could allow me to do almost the same, so what do you think ?The benefit of their approach is what you describe -- their approach prevents the application (sample) from having a dependency on d3d9.dll. If you call Direct3DCreate9 directly, a dependency on d3d9.dll will be included in your application's headers. When the windows loader attempts to load your exe, it'll also attempt to load d3d9.dll, and if not found, it'll display the "DLL not found in the following path: [DUMP all search paths here]" message box and die.   ;Quote:Original post by Muhammad HaggagNo, it's not safe. On my 64-bit system (and others), the 32-bit d3d9.dll will be in System\SysWow64.I guess on Vista, GetSystemDirectory (it's equivalent, actually) would return that directory, so it would just be fine, wouldnt it?Quote:Original post by Muhammad HaggagThe benefit of their approach is what you describe -- their approach prevents the application (sample) from having a dependency on d3d9.dll. If you call Direct3DCreate9 directly, a dependency on d3d9.dll will be included in your application's headers. When the windows loader attempts to load your exe, it'll also attempt to load d3d9.dll, and if not found, it'll display the "DLL not found in the following path: [DUMP all search paths here]" message box and die.Thanks for your reply. Does what you say still holds when you enable /DELAYLOAD under visual studio ? I guess that would be a little bit cleaner, cuz the GetProcAdress to wich you pass the function name as a string array of char (!) really looks ugly to me.Regards,Janta   ;Quote:Original post by jantaQuote:Original post by Muhammad HaggagNo, it's not safe. On my 64-bit system (and others), the 32-bit d3d9.dll will be in System\SysWow64.I guess on Vista, GetSystemDirectory (it's equivalent, actually) would return that directory, so it would just be fine, wouldnt it?First, there are 64-bit XP and 2003 Server systems -- it's not only for Vista [smile]. The way this WOW64 (Windows On Windows 64, IIRC) works is that if the executing application is 32-bit, the environment variables (e.g., the one returned by GetSystemDirectory) get expanded to point to the 32-bit ones (In SysWow64).Quote:Thanks for your reply. Does what you say still holds when you enable /DELAYLOAD under visual studio ? I guess that would be a little bit cleaner, cuz the GetProcAdress to wich you pass the function name as a string array of char (!) really looks ugly to me.Yes, the same problem will occur with delay-loading. Delay-loading delays the loading of the dependency until it's first referenced. That is, Windows will only attempt to load d3d9.dll when you call call Direct3DCreate9. When you do, it won't find it, and crash and burn with the same "DLL not found" error.What you can do, however, is use delay-loading, and attempt to load d3d9.dll using LoadLibrary before calling Direct3DCreate9. If you successfully load it, it exists, and you can happily unload it for now (and let Windows load it for you later). If you can't load it, it doesn't exist, and you can tell your user to get it.   