It also seems like you are asking about the difference between the dynamic libraries (dll), import libraries (lib) and statically linked libraries (also .lib)
You need some history.
I'll focus on the DOS world, but know that other operating systems had similar issues and everyone used a similar solution.
Go back a few years and recall that hard drive space was tiny. I recall when expensive hard drives were about 10 megabytes. (I also recall when PCs didn't have HDDs, you had two floppy bays...) By the time Windows 3.0 became commonplace in the work environment, hard drives were around 20MB, sometimes as low as 10MB and occasionally as high as 40MB. (DOS at the time was limited to 32MB on a drive, so people with 40MB drives would frequently have a 32MB programs drive and an 8MB drive for their documents and work.)
DOS and all its trappings on a hard drive was about 1 MB. Windows, however, was a beast. A minimal Windows 3.0 install took about 7 MB, more if you needed custom drivers such as for your graphics card and your printer and your mouse, and of course you wanted to install optional programs like solitaire and minesweeper. For many customers installing Windows required between a quarter to half your hard drive. That didn't leave much room for programs or data.
One of the big problems was the size of applications. If you linked against the Windows libraries it could add considerably to your program size. Your app without the Windows interface might be 150KB, but by the time you added in all the Windows stuff it would grow to 500KB or more. That was a lot of space on top of what Windows already required.
So the solution was to share libraries between programs. You could statically link your libraries which pulled in a copy of all your libraries, or you could share the file with many programs. This especially made sense for Windows core files, things you see today as kernel32, gdi32, and user32, comctl32, among others. You could access the functions using the shared library without including all that code in your program.
But how do you access the functionality?
In order to call a function in one of those libraries you need to load the library or fail gracefully if the library isn't present. Then you need to look up the function's address in the library and turn it into a function pointer. Then you can call the function. Every single time you used it, you needed to call LoadLibrary() when it starts, GetProcAddress() on the functions, and FreeLibrary() when you were done. But all those calls took up space and required effort. Space was precious and nobody likes writing near-duplicate code required for every function.
So they created something called an "import library". This is a mix of static and dynamic libraries. The compiler or other tools can automatically generate a very small static library that you link against. That small static library will automatically load the dynamic library, automatically hook up the function pointers, and automatically free the library when you were done. You could get all that work simply by linking to the library and it would automatically use the shared library.
You don't NEED to use an import library. You can still load the library manually, get the pointers manually, and properly free things when you are done. That should be all you need for the answers...
1) whot is inside of this - are there winapi functions used for loading module and getting adress of module functions
2) are this generated by some automat or this is hand coded?
3) is there some cost (overhead) added compared to dynamic linking calls?
1) There are some functions, basically just LoadLibraryEx, GetProcAddress, that get called for you. There are function pointers, and they get hooked up for you. There is a little bit of code to hook up shared variables, and initialize some static variables, and do a tiny bit of other work. There is code to unload the library when the program completes. There is also some error handling code that gets hooked up for you.
2) It is almost always automatically generated by compiler options. (Remember the purpose: to avoid work. That almost always means automatically being built.) You need to mark your functions to automatically generate it by using the dllexport attribute.
3) There is no additional cost. Either way the code will need to load the library and hook up the functions. The import library does this automatically when you start the program. If you were to load the library manually you would have exactly the same cost at a different time; not necessarily at the start of the program.
Note that sometimes you cannot use an import library. For example, if you are writing a plug-in system where other programmers can create a .dll and have it run with your program. In these situations you still need to load the library and look up functions by your own code.
Hope that helps.
