How do I use a dll file??

Hi,

I have a general idea of what dll file does. From my understnading, we can write a set of useful functions and data and can compile it to a dll format. But if we want to have other programs access this dll's functions, we need to "export" the functions using .def file or by inserting some Microsoft specific directives in the code.

But I was a bit confused when I saw some legacy automated test scripts at my work. The scripts had some lines like

Code:

---

nunit-console.exe unittest.dll

---

Here nunit-console.exe is a test framework that does unit testing by utilitizing functions defined in unittest.dll. But when I did dumpbin.exe /EXPORTS unittests.dll, I couldn't see any function that was exported. I tried with /all option but ended in vain.

nunit-console.exe is a largely available 3rd party testing harness, and unittest.dll is something a developer at my work wrote. This may seem a stupid question, but then how can nunit-console.exe access information (whether it's function or data) in the dll file if no functions were exported?

Thanks in advance.

Maybe it just runs it? ie loads it so DllMain() or whatever it's called is run.

You don't always need .def files, that's a Visual Studio thing.
You just need LoadLibrary, FreeLibrary, and GetProcAddress to load functions from a dll. I guess that script gets the dll from command line and loads it.

If you're interested in using DLLs, try a Simple Message box loading from a DLL tutorial.

Quote:

---

Originally Posted by execute

You don't always need .def files, that's a Visual Studio thing.
You just need LoadLibrary, FreeLibrary, and GetProcAddress to load functions from a dll. I guess that script gets the dll from command line and loads it.

If you're interested in using DLLs, try a Simple Message box loading from a DLL tutorial.

---

However, GetProcAddress requires the function to be exported, either as a ordinal (numeric) or as a named function. If there are no exports, I don't know how it works - probably like zacs7 suggests: It calls dllmain, and it all unravels from there.

--
Mats

Quote:

---

Originally Posted by execute

You don't always need .def files, that's a Visual Studio thing.
You just need LoadLibrary, FreeLibrary, and GetProcAddress to load functions from a dll.

---

No, it's not a "Visual Studio thing". It is another way of linking and using functions from a DLL. The way you describe is the way I would call dynamic. .Def files is another way I like to call static.

IIRC .DEF files are only used to prevent name mangling (exported name can be corrupted, preventing calling).

All they contain is a list of function names in order, not full declarations.

A WIN32 C app I worked on required the use of .def files (as well as the .lib) to dynamically call a WIN32 C dll.

Dynamic linking allows you to 'drop-in' a new DLL and run without recompiling. Static linking forces you to link with the static export lib of the DLL and thus any changes in the DLL must be recompiled into the static export lib.

Dynamic linking is more complex but more flexible. Static linking is a snap but not flexible at all.

Dynamic linking will require you to use LoadLibrary() and GetProcAddress() and static linking will only require you to use a header to define a constant as dllexport or dllimport.

Quote:

---

Originally Posted by Bubba

Dynamic linking allows you to 'drop-in' a new DLL and run without recompiling. Static linking forces you to link with the static export lib of the DLL and thus any changes in the DLL must be recompiled into the static export lib.

Dynamic linking is more complex but more flexible. Static linking is a snap but not flexible at all.

Dynamic linking will require you to use LoadLibrary() and GetProcAddress() and static linking will only require you to use a header to define a constant as dllexport or dllimport.

---

There is also delay-load linkage. It works like static linkage, but loads the dll only on first call to its function. So application could check the presense of the dll, using LoadLibrary function, and if the dll is not found - just disable the part of the code that uses the functions of the dll (and so the dll will never be loaded and user will not see the "Missing file" message), but there is no need to use this GetProcAddress crap

Well, sometimes (not often) it is beneficial to manually load and link the DLL. I have had to do it before a couple times, but only rarely and for specific reasons.

Quote:

---

Originally Posted by abachler

Well, sometimes (not often) it is beneficial to manually load and link the DLL. I have had to do it before a couple times, but only rarely and for specific reasons.

---

The most common scenario of this is when you have several choices for an interface type DLL - e.g. a DLL that knows different models of cameras or scanners to import pictures to the photo editor. By choosing the right DLL, the photo editor in itself doesn't need to know how to import an image from a Canon EOS 10D or a Fuji FinePix 1234 or a HP ScanJet 4567. Instead, a DLL for each of those models can be produced to provide this functionality.

Another example would be in the photo editor that wants to be able to load/save many different file formats. Instead of having the application in itself know how to load the content of a JPEG, TIFF, BMP, PNG, etc, etc, we write a DLL that knows how to deal with each format, and when the application is asked to open a JPEG, it loads "LoadSaveJpeg.DLL", and calls it's Load() function with the name of the image.

--
Mats

This is a nice little class for dynamic DLL use.