0

I want to ask whether the library.lib file generated when creating a dynamic library contains some kind of memory location reference to the function of the dynamic library?

How exactly does the executable find and resolve the functions either at load time or runtime?

In visual studio, the dynamic library .dll and static library .lib are created by creating a library application, followed by generating the header file and .cpp file representative of the library to be included into other source codes and finally compilation.

The library is then used by another program source code by using the include directive on the header file, then followed by declaring the location to header files of the library under additional include directories. Then settings additional dependencies to the static .lib file generated previously also called DLL import library. A post build event is then set in order to copy the .dll file into the local working directory of the executable.

DLL import library, what exactly is contained in this static library which i guess provides instructions to resolve functions in the dynamic library?

Thanks

Yogi Bear
  • 3
  • 4
  • Has the DLL been registered? `regsvr32 "C:\Windows\System32\myfile.dll"` – Eljay Jun 28 '21 at 12:49
  • Doesnt answer the question... You don't need to register dll's in order to use them, the exceptions are COM and ActiveX model implementations . In that case, what is responsible for resolving the functions at load or runtime? Specifically, what is the code structure for resolving dynamic library functions – Yogi Bear Jun 28 '21 at 13:25
  • Maybe someone who has designed compilers could provide some details, would be helpful – Yogi Bear Jun 28 '21 at 13:28
  • In that case it's the [standard search order for desktop applications](https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications). – Eljay Jun 28 '21 at 13:29
  • If your question is why `.lib` file needed - [this](https://stackoverflow.com/a/42295558/4074081) seems to be a good explanation. It is kind of "always static" linking on Windows, compared to Linux where symbols resolution is performed at runtime and you can for instance use `LD_PRELOAD` to override `malloc`/`free` with your own implementation. – dewaffled Jun 28 '21 at 13:35
  • When you create `my_dll.dll` you also get `my_dll.lib`. This library is not a static library in the traditional sense (contains your code), but a "fix-up" only library. It satisfies the missing externals that the linker of `your_app.exe` needs but only in the form of _"stubs"_. When `your_app.exe` is run the OS loader see the stubs, loads `my_dll.dll` and fixes up the stubs to point to the real code in the dll. This process is repeated for any dependent dlls. It's very similar to `LoadLibrary` followed by `GetProcAddress` but done in bulk. – Richard Critten Jun 28 '21 at 14:05

0 Answers0