DLL Imports?
Author
I don''t know if this matters, but why does MSVC++ dependency viewer say that my apps import from dlls like opengl32.dll, dinput8.dll, etc, but when I look at an executable from a game that I know uses OpenGl or something, it shows nothing like that. In every game I have tried, there is no import from any DirectX or OpenGL dlls. Also, it is worth a mention that the samples that come with the DX sdk do show imports.
The dependency viewer and even different decompilers show list of DLLs that were imported due to linking of LIBs which represent this DLL. I mean, if you link opengl32.lib then you''ll see opengl32.dll in a list of imports, but if you load DLL by yourself (using LoadLibrary ()) you won''t see any imports.
Why is this so? I don''t know
Why is this so? I don''t know
As Antoxa mentioned, you won''t see imports if the DLL is manually loaded - the only imports the dependency viewer will find are those that are automatically loaded at program startup by the OS, it doesn''t have pointers to the rest of the information to find out about the other files.
The most likely reason however is that the games you examined had plugin renderers - like many current games, which would mean that you''d need to examine the plugin dll''s to find the references to DirectX, OpenGL et al.
The most likely reason however is that the games you examined had plugin renderers - like many current games, which would mean that you''d need to examine the plugin dll''s to find the references to DirectX, OpenGL et al.
A quick sketch:
The functions imported by a statically linked library are put into the import table section of the PE File. Depends (et al) read from that table. In contrast, dynamically linked functions are formed from a function pointer and a couple of strings at run time (see GetProcAddress). These strings are stored in a different section of the PE File - the data section typically. A utility that scans binary files for strings - or a simple hex editor for that matter - might reveal something of the strings used for dynamic linkages.
The functions imported by a statically linked library are put into the import table section of the PE File. Depends (et al) read from that table. In contrast, dynamically linked functions are formed from a function pointer and a couple of strings at run time (see GetProcAddress). These strings are stored in a different section of the PE File - the data section typically. A utility that scans binary files for strings - or a simple hex editor for that matter - might reveal something of the strings used for dynamic linkages.
Author
Ah, so some programs dont actually link through the compiler. Never really thought about why they're called _dynamically_ linked libraries.
So how (code-wise) do you link like that, without libs? And what are the advantages?
Thanks
Edited by - Kranman on December 13, 2001 10:55:00 PM
So how (code-wise) do you link like that, without libs? And what are the advantages?
Thanks
Edited by - Kranman on December 13, 2001 10:55:00 PM
To "link" dynamically, you load the .dll via LoadLibrary(), and then using the handle returned for the library, you use GetProcAddress() to load each function. Generally you also have to typedef the function prototypes to a type and declare a variable of that type to hold the function pointer. You also call the function through that variable.
I don''t know how to insert code snippets here, or I would show you an example.
Also, for DX, most of the objects are COM objects, so you don''t link statically/implicitly to them. They are loaded dynamically by COM when you can CoCreateInstance() (or Direct3DCreate8(), which probably calls CoCreateInstance() underneath).
It''s a lot more work to dynamically load functions.. so unless you are creating a plugin architecture or something, just link to the import .libs.
-Brannon
I don''t know how to insert code snippets here, or I would show you an example.
Also, for DX, most of the objects are COM objects, so you don''t link statically/implicitly to them. They are loaded dynamically by COM when you can CoCreateInstance() (or Direct3DCreate8(), which probably calls CoCreateInstance() underneath).
It''s a lot more work to dynamically load functions.. so unless you are creating a plugin architecture or something, just link to the import .libs.
-Brannon
If you are interested in this I can recommend Dependency Walker, a free app that is excellent at finding this info out for you. I use it all the time when working out which files to include in an install (of course now that the MSI tech has it''s MSM''s this need should evaporate). Anyhow point yer browsers at http://www.dependencywalker.com/ and have fun.
Author
I was expecting that you''d have to declare a bunch of function pointers. But that seems like a lot of trouble? Why would you use this method instead of just using the libs?
Import .libs do the dirty work for you (loading the DLL, fixing up the function pointers, etc)... but they are static. You always load the same DLLs. If one is missing, your app wont even load. Dynamically linking allows you to load a DLL at runtime and call functions exported from it. You can make plugins like this.
-Brannon
-Brannon
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
