Why does visual studio create a .LIB along with the .DLL?

Question

I have a project "Logger" wherein the configuration type is .dll.

"Logger" uses "libconfig" (an open source config parser). Currently, I have a separate project for "libconfig" and its configuration type is .lib

I added "libconfig" to Logger's frameworks and references setting with:

• link library depedencies = true
• use library dependency inputs = false

In Logger's linker command line, i see: /IMPLIB: "path\to\Logger.lib"

My question is: Why does Logger.lib need to be created? I see /OUT = "path\to\Logger.dll", but I'm trying to get a hang of visual studio's build process.

From M$'s IMPLIB doc, I see its part of the LINK process. I still don't get it.

Edit: I didn't mention how the Logger DLL was to be used. My application would be loading it at run-time (since this functionality is only required for specific cmd line args)

Answer 1

The DLL contains the code. The .lib file contains basically stubs for the functions in the file, that make it easy (and relatively fast) for the linker to put the correct information into an executable to use functions in the DLL.

Ultimately, there's no reason they'd have to do this -- it mostly keeps the linker a little simpler and faster, because it doesn't need (at least as much) special case code to deal with static vs. dynamic libraries. They could get around that by putting both the code and the linking information into a single file, but that would increase the file size (a little).

It probably doesn't mean much now, but back when Windows was new, quite a few programs were still distributed on 360K floppy disks, so minimizing the size of file you distributed to users was considered fairly important.

Answer 2

An exe that uses your logger.dll is going to need to link to logger.lib. Without the lib the exe cannot be built. The lib contains stub functions that satisfy the calls made by exe code. (At runtime the stubs transfer the calls into the DLL.)