So, dynamically linked program works as follows:
-The main program is loaded to memory
-The main program uses LoadLibrary() function load a dll file onto memory; the function returns a handle
-The main program needs to search for the address of the function inside the dll it wants to call using GetProcAddress()
-Call the address returned by GetProcAddress()

And a statically linked program works as follows:
-The main program is loaded to memory
-The main program automatically loads all the dll libraries that is statically linked to
-The main program already knows the addresses of the functions it wants to call so no need to use GetProcAddress()
-Functions can be called without using GetProcAddress()

The differences between dynamically or statically loading a library is that:
-Statically linked libraries are somewhat faster since we don't have to perform LoadLibrary() and GetProcAddress() just to call a function inside a dll file
-One thing i tried was FreeLibrary() on both statically and dynamically linked programs. Dynamically linked programs did free up memory and dll functions can no longer be called. On the other hand, statically linked library said that it freed up the library but no memory space was freed up and i could still call the functions inside the dll.

The similarities i found were the that:
-Both load the linked libraries onto memory
-Both require the dll files to be present

At first, i thought that statically linking a library actually exports the entire function onto the main program. Only after playing around i found out that it only does a small optimization. It is the speed vs size kind of trade off. Dynamically linked libraries would have come handy in the old systems with little memory. Because most modern machines have sufficient memory; it is faster to call statically linked functions since there is no need to use GetProcAddress().

So, it makes me beg this question. Is there a way to export an entire function from a dll file with no linking or loading a separate process whatsoever?
Posted on 2011-01-12 05:59:00 by banzemanga
I think your terminology is a tad confusing.
In both cases you are talking about DLLs (Dynamic Link Libraries). These are *always* linked dynamically, hence the name. There are also regular libraries (.lib files, basically a collection of .obj files).
What you are describing is two ways of using a DLL:
- By using the companion static link library, which will add the imported functions from the DLL to the import section of your executable, and have the PE loader take care of loading the DLL and finding the function addresses automatically (although still dynamically: the code is still linked to your executable at runtime, so you can update the DLL, and it will still work, as long as the DLL has the same name and exports the same functions).
- By manually loading the DLL into memory and manually importing the functions (LoadLibrary/GetProcAddress, known as run-time dynamic linking).

Statically linked libraries (as in regular .lib, not DLLs) are when the code is already embedded inside your executable. In that case, the function addresses are resolved by the linker, not at runtime. But that is not something you can do with DLLs.
What you COULD do (assuming you're the one writing the library), is to first build your code as a  static library with all the main functionality. And then you build a DLL around this. This way you can choose whether to link your code statically or dynamically.

As for GetProcAddress() efficiency... obviously that is mostly in your own hands. When using the .lib that comes with a DLL, the linker will add some function pointers to your executable (usually something like __imp_myimportedfunction, which may go indirectly, by first making a jump, then a call, depending on the linker). The PE loader will then store the results of GetProcAddress() into these function pointers, and your code will call these functions pointers directly. Therefore the cost of GetProcAddress() is only at load time. During runtime, the only extra cost compared to local functions is that your calls go through a function pointer in memory, rather than an immediate operand.

If you load DLLs with LoadLibrary(), you can mimic this behaviour by allocating your own function pointers, and storing the results of GetProcAddress().
Something like:

.data
myDll db "MyDll.dll",0
myFunction db "MyFunction",0

.data?
myFuncPtr dd ?

.code
push offset myDll
call LoadLibrary

push offset myFunction
push eax
call GetProcAddress
mov , eax

...

call


This should have the same performance as using a library (.lib) at the linking stage, and having the PE loader import the functions automatically. The only difference is that it requires more code. I wouldn't recommend this approach unless you really have to (eg, you don't know whether a DLL is present on the system or not, and static linking to the DLL would make it crash on startup).

Also, I wouldn't really worry about performance differences between DLLs and static libraries. There may be slightly more calling overhead, but that should be negligible compared to the amount of time the actual function takes. If calling overhead matters, then you should consider inlining the functions rather than depending on libraries.

In general I would say that you should use DLLs only when there's a good reason for it. This could be because your library contains code that you want to share between multiple applications... or when you want to implement some kind of plugin system, where you dynamically load code from DLLs at runtime, allowing users to easily install extra functionality.
If your code is not going to be shared with other applications anyway, then a DLL will only add more size to your code (it is a separate PE file, with its own headers and such, adding another few KB to the code). And more DLLs means more difficulty with distributing and installing your application on other systems etc.

As for FreeLibrary()... if you use LoadLibrary() to get a handle to the DLL, it will increase the reference count (and FreeLibrary() will decrease it). If you use GetModuleHandle(), the reference count will not be increased, so with a statically linked DLL, using GetModuleHandle() and FreeLibrary() should set the reference count to 0 and unload the DLL.
Posted on 2011-01-12 06:48:19 by Scali
I think your terminology is a tad confusing.

Sorry about that. I tried to use less terminology and more raw language since terminology itself can be confusing as well.

Also, I wouldn't really worry about performance differences between DLLs and static libraries. There may be slightly more calling overhead, but that should be negligible compared to the amount of time the actual function takes. If calling overhead matters, then you should consider inlining the functions rather than depending on libraries.

That is why i said that it is a speed vs size trade off. In the old times where then was 1MB ram limit dynamic linking of DLL was very important. In current times where ram is more than sufficient, the size overhead is almost none. That is what i said.

In general I would say that you should use DLLs only when there's a good reason for it. This could be because your library contains code that you want to share between multiple applications... or when you want to implement some kind of plugin system, where you dynamically load code from DLLs at runtime, allowing users to easily install extra functionality..

I completely agree with you.

As for FreeLibrary()... if you use LoadLibrary() to get a handle to the DLL, it will increase the reference count (and FreeLibrary() will decrease it). If you use GetModuleHandle(), the reference count will not be increased, so with a statically linked DLL, using GetModuleHandle() and FreeLibrary() should set the reference count to 0 and unload the DLL.

I did use GetModuleHandle() and then FreeLibrary() to unload the dll on the static linked DLL it was not unloaded. In other words, the statically linked library doesn't unload even though FreeLibrary() returned that the operation was successful.

Yes, i agree with you that DLL files should be used within its own purposes. I have a somewhat very different purpose in using the DLLs. I want completely export some of the DLL functions inside my main program and not linking it.

Like i said, at first i thought that static linking with DLLs would "export" the functions inside my program. I was wrong. What static linking really does is to resolve and store the function addresses so that i can directly to perform the function calls.

Think of it this way. There are some DLL libraries that contain some functions you want to use. You don't want to link your program to the DLL but you want to use those functions on your program. So, you want to export the source code of those functions and import in then into your program. How do you do that?
Posted on 2011-01-12 07:22:50 by banzemanga

That is why i said that it is a speed vs size trade off. In the old times where then was 1MB ram limit dynamic linking of DLL was very important. In current times where ram is more than sufficient, the size overhead is almost none. That is what i said.


Still not sure what you mean with 'dynamic linking of DLLs' in this context.
I would say that nothing has changed really... Basically the following held back then, and still hold now:
1) Don't use a DLL unless you really have to. Code that is not shared is better linked statically in the binary than stored in a separate DLL.
2) Don't use run-time dynamic linking unless you really have to (more code, more work, more chance of problems).

I did use GetModuleHandle() and then FreeLibrary() to unload the dll on the static linked DLL it was not unloaded. In other words, the statically linked library doesn't unload even though FreeLibrary() returned that the operation was successful.


That could be. It's safer for the OS to ignore FreeLibrary() on any libraries that have been loaded by the PE loader. Perhaps modern versions of Windows silently ignore the call.

Yes, i agree with you that DLL files should be used within its own purposes. I have a somewhat very different purpose in using the DLLs. I want completely export some of the DLL functions inside my main program and not linking it.
FreeLibrary() is not strictly required anyway, as DLLs will get unloaded when the process terminates anyway. I think I read somewhere in MSDN that they advise to no longer use the function.

Like i said, at first i thought that static linking with DLLs would "export" the functions inside my program. I was wrong. What static linking really does is to resolve and store the function addresses so that i can directly to perform the function calls.


That is correct.

Think of it this way. There are some DLL libraries that contain some functions you want to use. You don't want to link your program to the DLL but you want to use those functions on your program. So, you want to export the source code of those functions and import in then into your program. How do you do that?


This happens automatically. The OS will memory-map your PE files (both .EXE and .DLL) files. This means that nothing will be loaded until the memory is accessed for the first time. Then it will map that particular page (usually 4KB) into memory. So if you call a function from a DLL, then the page of memory that this function resides on, is loaded from disk. Functions on different pages will not be loaded until they are accessed.
Likewise, the swapping algorithm inside Windows will also swap out the least-recently used pages again, after a while. So if functions from a certain page have not been called in a while, they will be unloaded again, if necessary.
You can see this behaviour with services for example. They generally take only a few KB of memory when they're idle, since all the unused code is not mapped.

But there is no way of extracting the code from a DLL and linking it into your executable at link time, as if the DLL was a regular static library, if that's what you're asking. But, see above... since it was built as DLL, there's a good reason why it's a DLL and not a regular static library, so there are advantages to it being a DLL.
In theory one might be able to build a tool to convert a DLL to a COFF object file though... but I don't know of any such tools, nor do I see a reason why they should exist.
Edit: Apparently someone bothered to build something like that: http://www.binary-soft.com/dll2lib/dll2lib.htm
No idea if it works.
Posted on 2011-01-12 08:17:36 by Scali

You can see this behaviour with services for example. They generally take only a few KB of memory when they're idle, since all the unused code is not mapped.

Yes, i agree too. Services are a great example on why to use DLL files.


But there is no way of extracting the code from a DLL and linking it into your executable at link time, as if the DLL was a regular static library, if that's what you're asking. But, see above... since it was built as DLL, there's a good reason why it's a DLL and not a regular static library, so there are advantages to it being a DLL.
In theory one might be able to build a tool to convert a DLL to a COFF object file though... but I don't know of any such tools, nor do I see a reason why they should exist.
Edit: Apparently someone bothered to build something like that: http://www.binary-soft.com/dll2lib/dll2lib.htm
No idea if it works.

I tried it but too bad it is not working for me. Interestingly during the conversion it even added a MessageBox object that is nowhere found in my custom made DLL file. lol

Thanks for trying to help. I will guess i do some dig around myself.
Posted on 2011-01-12 12:14:03 by banzemanga

Yes, i agree too. Services are a great example on why to use DLL files.


Well, that's not really what I meant.
DLLs are no different from EXEs in this sense. They're all PE files, and they all get memory-mapped.
Even a service consisting of only a single EXE file would get swapped out when not in use.

Windows itself is a good eaxmple on why to use DLL files though. The API is implemented in DLLs and as such, all the API function code can be shared between all Windows applications.
Posted on 2011-01-12 12:40:57 by Scali