Some basic questions about the DLL file.

Question

1. When does Windows Operating System load a DLL into memory?
2. Does the operation occur when the application starts or when the application first calls one of the procedures in the DLL?
3. Could a DLL be unloaded once it has been loaded?

Answer 1

I'm going to assume we are talking .net. It is garanteed to happen before you need the code. But you can use late binding to do it at some other time. See this pagelink text

Answer 2

In the windows API, you can explicitly control the loading and unloading of a .dll.

See LoadLibrary and FreeLibrary as a starting point.

Depending on the language/tools you are using many of the details of loading libraries will be taken care of for you, but usually you can still get explicit control if you really want it.

Answer 3

When does Windows Operating System load a DLL into memory?

If you've linked your EXE to a DLL implicitly through a .lib file, like you normally do for most windows apis such as user32.dll and kernel32.dll, then the defautl behavior is for the DLL to get loaded when the process starts and before your WinMain/main function is called. See below for delay loading...

If one DLL depends on another, it will load its dependencies first if they are not already loaded.

If you are explicitly loading code through a DLL (LoadLibrary, CoCreateInstance, etc...), then it will get loaded upon making these calls

Does the operation occur when the application starts or when the application first calls one of the procedures in the DLL?

You can have it both ways. By default, DLL is loaded at app startup. If you used the /DELAYLOAD linker flag, the DLL may be able to defer being loaded until its actually needed. This is "best effort" - if there are weird export dependencies with global variables, it may not work.

Could a DLL be unloaded once it has been loaded?

Short answer is "no" for implicit DLL dependencies that you've linked. FreeLibrary and CoFreeUnusedLibrary can be used for LoadLibrary/CoCreateInstance calls.