how .dll linking works

[Dewey1040]

I've recently created a .dll project in Visual Studio using C++.

I'm curious how Visual Studio is creating the ability to link the files. I got everything working properly but it seems I can get the project to work flawlessly regardless of where the .dll file is located.

Once the .exe file is created by VS is this runnable without the .dll file? or the .h file? It seems I can run the file with no problem from any folder even when I move the .h and .dll files... I'm not quite sure how this is possible unless the .exe file just has everything it needs and VS only creates the .exe with all the information then you can export the .exe file anywhere.

I've always been working in a unix environment until recently so it's just confusing to me how a main.cpp file can be compiled then run without knowledge of the location of header files or .dll files.

[mike_2000_17]

The header files are certainly not needed once the compilation is over (nor are they needed in unix environments). Normally, the DLL file should be required in order for the executable to work (if the DLL is actually used by the executable). With Microsoft products, it works as follows (for MinGW GCC it actually works the same as in unix environments (i.e., ELF)). You have basically 4 files that are important to explain this:

1. The source code for the executable, let's call it "main.cpp".
2. The header file that declares the DLL functions, let's call it "my_code.h".
3. The compiled DLL with all the functions, let's call it "my_code.dll".
4. A static import library generated while compiling the DLL, let's call it "my_code.lib".

When you write "main.cpp", you need to #include the header "my_code.h" to let the compiler know about the functions that you are using. Then, you must tell the compiler (or more precisely, the linker) that you wish to link to the import library "my_code.lib". This import library is where the linker will be able to find all the symbols (or hooks) for the "my_code" functions that you are calling in "main.cpp". This import library doesn't actually contain the code of the DLL, it just contains some initialization / finalization code to fetch and load / unload the DLL dynamically (while your executable is being loaded before it runs, and after it has finished running). So, all the functions (symbols or hooks) that the import library contains (which the linker uses) are just wrappers that forward the calls to the DLL (once loaded). So, finally, when executing, you need both the executable and the DLL for everything to work.

Now, if it works "without the DLL", it might be one of two things that I can think of. First, the code that finds and loads the DLL before the executable starts running will actually search for the DLL file. Of course, it won't search everywhere, usually just in the system folders (system and system32 folders) and in the executable's folder (and probably it's sub-folders, and possibly other folders that you set by linker options). So, the actual location of the DLL is a bit flexible, so that might explain your confusion. The other possibility is simply that if your DLL is too simple (e.g., for a small test program to play around with DLLs), then the compiler might figure out that there is no point in making it a DLL, because of all the additional overhead that it implies. So, the compiler might just choose to put all the actual compiled code for the functions into the "import library" making it just a static library because it no longer binds to the DLL. If that is the case, then you obviously don't need the DLL to run it (it would still produce a DLL with valid code in it). This second possibility is really just speculation, I have no insight into the MSVC compiler/linker to know if that's even something the compiler would ever do.

[Dewey1040]

Thanks a lot for the response, and sorry for the delay getting back. Your response was very helpful and although my dll file was really just a basic test file to square a few numbers I highly doubt that Visual Studio would check for the size of the .dll and be able to run the program without the .dll knowing that it was so small. Why would VS still create the .dll file if that was the case?

Your first reason sounds much more reasonable, as the file was copied into a few different locations and the program could have easily found it looking through a few different directories.

[mike_2000_17]

I highly doubt that Visual Studio would check for the size of the .dll and be able to run the program without the .dll knowing that it was so small.

I doubt that very much too. In any case, it wouldn't be a matter of seeing that the DLL is so small and decide to integrate it to the exe. It would be the case that when generating the DLL and its associated import library (.lib file) it would judge that it is better to generate the DLL and a static library (still .lib extension) which does not "import" the DLL functions but rather "contains" the DLL functions (sort of a static version of the dynamic library).

Why would VS still create the .dll file if that was the case?

Because there are other ways to import functions from a DLL, namely through a LoadLibrary / GetProcAddress / FreeLibrary procedure. If VS were to generate a static library instead of an import library, it must still generate the DLL because you might want to use the DLL through that LoadLibrary / GetProcAddress / FreeLibrary mechanism. But, again, I highly doubt that VS would do this at all, but possible.