   Directx DLLs and Libs
  Im using VC++ and Im a bit confused about all this:1) When I add d3d9.lib to the project in the link settings, does it mean that the lib will be inside the exe and the user that runs the process doesn't need to have d3d9.dll in his machine?2) Does debug/release modes affect anything in the way the libs or dlls are loaded?3) Where is the code (assembly) of all the methods of the classes located? And how to locate them?I tried for example to look at the assembly code of calling the SetRenderState method of IDirect3DDevice9 and the CALL goes to about address 0x00b00000 which isn't even near the area of the functions like Direct3DCreate9 (about 0x4f000000).Anyway, Some clear explanation would do the trick, I'm just totally mixed up with this right now, please help...   
  1) No. The end user still needs the DirectX runtime installed. The lib only provides the symbol resolution for the load time DLL patch ups.2) The process of how DLLs are loaded is the same; however, which DLLs are loaded might be different.3) Could be anywhere. Once you make the call to the DirectX runtime you shouldn't really concern yourself what happens.   ;  But the code itself of all the methods is inside the DLL isn't it?   ;  Not necessarily. The DLL could just call code somewhere else, such as inside kernel space, which is memory you cannot access.   ;  I dought that, the size of d3d9.dll is about 1.5MB which means that it can't have just 10-15 functions (the number of functions I can export from the dll), I think that it contains all of the methods too. But how to to find the specific address of each method?Oh, and I do get access to the methods, but the thing that bothers me is that the address of them is somewhere in the area of 0x00b00000 and the area of the global functions is in 0x4f000000   ;Quote:Original post by UriKillerI dought that, the size of d3d9.dll is about 1.5MB which means that it can't have just 10-15 functions (the number of functions I can export from the dll), I think that it contains all of the methods too. But how to to find the specific address of each method?Why do you want to? There's no reason to. D3D9.DLL only exports one function - Direct3DCreate9(). That function returns an interface (IDirect3D9). The interface has a virtual function table (Think of it like a struct containing a load of function pointers), and each entry in the vtable points to one of the member functions of IDirect3D9.1) No, as SiCrane said - d3d9.lib is just a bunch of statements saying where each exported function is in d3d9.dll, it doesn't say anything about the code itself. There's two types of .lib file, one which is used to link to a DLL without having to use a load of GetProcAddress() calls, and one which actually includes the code.2) Nope. Both will link to the same version of D3D9. You can change what version that is in the control pannel (Where you can chose between Debug and Release runtimes).3) See above and below.The most probable reason why the two function calls are miles away is that when your D3D device is created, D3D will load another DLL, depending on the type of device you want to create. This is one of the advantages of interfaces, it doesn't matter what goes on behind the scenes. A HAL device is probably in a different DLL from d3d9.dll, and I know that a REF device is (There's a DLL called something like d3d9ref.dll). When you call IDirect3D9::CreateDevice(), D3D probably loads the appropriate DLL, and calls a function to return an IDirect3DDevice9 interface.   ;  Ok I'll check into that, thankyou.Actually, in second thought, I don't really mind telling what I am trying to do:I would like to make a little temporary change to the directx9 DLL which has the method SetRenderState - if the 2nd param is D3DRS_FILLMODE, then make the 3rd param D3DFILL_WIREFRAME. This would make all Direct3D9 programs run in wireframe mode, which helps to study how games are geometrically designed. So, any ideas how to do that maybe in another way? (trying to hack the games almost made me kill myself so not that option)   ;  <Shameless plug>You can try this: DirectX Tweaker It contains a wireframe plugin.</Shameless plug>   ;Quote:Original post by UriKillerOk I'll check into that, thankyou.Actually, in second thought, I don't really mind telling what I am trying to do:I would like to make a little temporary change to the directx9 DLL which has the method SetRenderState - if the 2nd param is D3DRS_FILLMODE, then make the 3rd param D3DFILL_WIREFRAME. This would make all Direct3D9 programs run in wireframe mode, which helps to study how games are geometrically designed. So, any ideas how to do that maybe in another way? (trying to hack the games almost made me kill myself so not that option)<sarcasm>I have a better idea: hack DirectInput so that you can bind a keyboard shortcut to a bool TakeScreenshot. Then, change SetStreamSource and DrawPrimitive functions so that every time TakeScreenshot==true, it creates a D3DXMESH object, saves all the geometry into it and exports it into a .x file. [grin]</sarcasm>   ;Quote:Original post by UriKillerOk I'll check into that, thankyou.Actually, in second thought, I don't really mind telling what I am trying to do:I would like to make a little temporary change to the directx9 DLL which has the method SetRenderState - if the 2nd param is D3DRS_FILLMODE, then make the 3rd param D3DFILL_WIREFRAME. This would make all Direct3D9 programs run in wireframe mode, which helps to study how games are geometrically designed. So, any ideas how to do that maybe in another way? (trying to hack the games almost made me kill myself so not that option)DirectX tweaker looks like what you want.The way (I presume) it works, is you just create your own d3d9.dll that provides a Direct3DCreate9() function. That function then creates a class derived from IDirect3D9, and you implement all of the methods in it and usually just call the real D3D function (You'd have to load the real D3D9.dll when you create your derived class, use GetProcAddress() to get the address of the real Direct3DCreate9() function, then call it to create a real IDirect3D9 interface you can call to).You'd need to implement your own IDirect3DDevice9 too, but you could get away without implementing everything like VBs, IBs, textures, etc.   