 |
|
|
Scene.org is hosted and supported by:
|
|
|
Scene.org is sponsored by:
|
|
|
|
|
 |
forum - #coders |
|
 | | Topic: | Dynamic libraries - the concepts? | | | Hi!
Can someone explain me in detail how dynamic linking works, what pieces of software like linkers, loaders and runtime environments is involved, what information a DLL file or other dynamic library formats consist of that is needed for the linker/loader and what information the executable file that links to dll`s etc must have + the whole mapping process from the exe and dll files to memory.
I know there is documentation about this, but ět`s hard to find and usually described in a very abstract way that doesnt tell me anything in detail.
Thanks. | | |
| | Search for articles mentionning 'Bugslayer' or 'John Robbins'. He's got a website called Wintellect.com but they only seem to have .NET articles nowadays. He wrote some articles on how to write a debugger, including how to import dll's and exe's, and how the mapping process generally works. I don't suppose you're aksing the sources of the kernel part where this is handled, because I've never seen that kind of info on the net (yet). | | |
| Ah, yes, DLL linking. It seems complicated, but it is really incredibly simple. Inside your EXE is a table of fuction names with their corresponding DLL file names. When the program loads, the OS loads all the requested DLL's into memory. It goes through your program's list of function names and replaces them with pointers to the function's physical memory location. Your program calls the DLL functions indirectly through these pointers. That is, you would not do "call MyDLLFunc". Instead, you do "call [__imp__MyDLLFunc]", where __imp__MyDLLFunc is the pointer to the funciton.
The linker's job is to buildthe table of function names and to ensure that all call statements refer to the table instead of some absoulute memory address. | | |
| I remember reading the PE (Portable Executable, the fileformat Win32 uses for DLL and EXE) specs some years ago. There was a field that had the address where the executable should be loaded in order to not do relocations (relocation is the process described by s_tec). I wonder: how stupid the PE designers could be? If you use the same linker twice (or more), the linker most probably will use the same address. If you load both executables in memory, only one of them will not require relocation. This is a very special case and the relocation process is almost zero time consuming. Well, there were other bad stuff in there... (f.e. why bother making PE a COFF-like format and not using COFF? MS wants to go by it's own way always...).
Btw, if you want to just implement dynamic linking, i recommend you reading the COFF specs at DJGPP's site (http://www.delorie.com/djgpp) or the ELF specs (somewhere at the net, available as PDF). I once implemented dynamic linking by creating a COFF-to-my_own_fileformat (COFF contains lots of unusefull information) convertor and then a small library that loads my fileformat. The whole process took me less than an afternoon (it's that simple). When i finished it, i had executables in a format that i could load and run without the need of recompilation under Windows, DOS and Linux (i had to implement -or just export(*)- the functions that the executables were using by making a host/loader).
(*)export: the dynamic linker doesn't make available all functions to the executables/libraries. Instead it has a list with the available functions (their name and their address usually - if you're going for security you may add a 'secure' field, meaning that only executables/libraries marked as 'secure' may use this function) and the linker, for each 'imported' (i.e. unresolved, unknown, not_implemented, whatever you name it) symbol (usually functions, but variables can be imported/exported too - they're just a pair of name and address), searches in the mentioned list for an entry with the same name. If found, then the relocation for that symbol in the executable takes place. If not, an error rises. The process of adding a symbol to that list is called 'exporting' the symbol. Now it makes sense: the linker (or a library, if you have average-to-good design in your dynamic linker) 'exports' a symbol and the executable 'imports' it.
I hope that i made some things clear :-). While i was looking for the topic at the internet, i found ...nothing. I had to e-mail to someone who actully implemented a similar to mine library and she explained everything nicelly. | | |
| Iirc, the base address can be relocated, but it doesn't have to be. You can also change this 'preferred' loading address using the rebase.exe tool that should be in your VC bin directory somewhere.
I've used the dbghelp.dll API to write a script engine on top of dynamically loaded DLL's, i.e. you can call all the exported functions including arguments. You can also do this using coffread.c directly, but it's not so clear what struct goes where. On top of this there are various different versions of the COFF 'standard', even in the *NIX community, which makes it essentially a non-standard anyways. I've build a C interpreter on top of this 'introspection' system which can run scripted C, with full access to all exported libraries. Next step is integrating a compiler/linker/loader that can compile the scripts to dll's on the fly and load them dynamically, so that the C scripts can run at full speed.
As for a girl implementing and explaining dynamic linking: now that's cool! :) | | |
|
|
|
