Below is an excerpt from link1.
Microsoft introduced __export in the 16-bit compiler version of Visual
C++ to allow the compiler to generate the export names automatically
and place them in a .lib file. This .lib file can then be used just
like a static .lib to link with a DLL. In newer compiler versions, you
can export data, functions, classes, or class member functions from a
DLL using the __declspec(dllexport) keyword. __declspec(dllexport)
adds the export directive to the object file so you do not need to use
a .def file.
I understand the above paragraph to an extent but not very well.
Below is an excerpt from link2.
When building the DLL, the linker uses the .def file to create an
export (.exp) file and an import library (.lib) file. The linker then
uses the export file to build the DLL file. Executables that
implicitly link to the DLL link to the import library when they are
built.
Now, this makes me confused and made me ask the below questions:
Could anybody, in simple words, tell me what the term exporting
really means? I believe this is making an object accessible from one
piece of the code to other - but hey !!
When building projects with old libraries, I see .def file in majority
of them. But the latest compilers automatically exports objects. Would
the presence of the .def file cause any conflict when converting a older
version visual studio project to the newer one?
What is the use of the .lib(the so called import file) after the generation
of the .dll. Can it be safely deleted?
ARRGGGH !! What is the difference between a static library(.lib) and import library(.lib)? Blunder, huh? But still !!
Is the windows specific phenomenon? I believe it is not. What is the Linux counterpart of the so called import file?
Please feel free to rephrase the question if it is not already lucid.
tell me what the term exporting really means?
It simply means telling the linker that it needs to put an entry into the DLL's export table. The operating system loader uses it later to glue code in different modules together at runtime.
I see .def file in majority of them
Could be very old projects. Or it was just never started as a project that was meant to create a separate module. Like a static library so the source code doesn't have the __declspec attributes. Cross-platform libraries are pretty likely to fit that bill. The C and C++ language specifications still don't have a way to create modules in a standardized way. Everybody does it, nobody does it the same way. Massive time drain.
What is the use of the .lib(the so called import file)
It is necessary in the project that uses the DLL. The linker needs to know that the identifier lives in another building and can't be resolved at link time. It puts an entry in another table that the operating system loader uses, the import table. It is a very simple file, it just list the names of the exported identifiers. Theoretically the DLL itself could be used by the linker to figure this out. Practically that doesn't work because the exported name doesn't have to match the actual name.
What is the difference between a static library(.lib) and import library(.lib)
A static library contains code that is linked into the project that uses the library. An import library does not contain code, just a hint that the code is available elsewhere.
Is the windows specific phenomenon?
Roughly, yes. The Unixes have the same concept but implement it very differently.
Related
I don't understand this paragraph :
Exporting functions in a .def file gives you control over the export ordinals. When you add an exported function to your DLL, you can assign it a higher ordinal value than any other exported function. When you do this, applications that use implicit linking do not have to relink with the import library that contains the new function. This is very convenient if you are designing a DLL for use by many applications because you can add new functionality and also ensure that it continues to work correctly with the applications that already rely on it. For example, the MFC DLLs are built by using .def files.
Why application doesn't have to relink with the import library in case of the usage of a .def file instead of __declspec(dllexport) in the case of a function adding into the dll ?
cf https://learn.microsoft.com/en-us/cpp/build/determining-which-exporting-method-to-use
That is because of some specifics of MSFT implementation of shared objects (or DLLs). In Microsoft world, in order to import function into your process, you need not only the shared code itself (.dll), but you also need the special 'import' library - the .lib file. This file is statically linked into your application (as it is a static library). This library provides 'glue' between function names and function ordinals.
Normally, every time you release a new version of DLL, all applications which use it will have to be relinked with the new, accompanying version of static import library (.lib) to be able to use this new DLL library. This is due to the fact that function ordinals are generally no longer valid after you have created the new library. However, if you are using .def file, you can assign ordinals manually, and ensure the ordinals remain the same for previously available functions - and thus .lib file will still be valid.
Ok, if you have a .def file you can use it to create an import library.
I.e. mydll.lib for MS VC++ or mylib-dll.a for GCC
Compilers and linkers prefer their own binary format import libraries, usually not compatible with each-other. This is especially does mater when you'r DLL is written on C/C++ but your program is written on something else like Ada/FORTRAN/Object Pascal etc or vise versa. So .def files can be used to create a compatible import library.
Paragraph telling you a way to hide some functions from import library, with manual editing .DEF file and instruct linker to hide some functions.
I have a library, written in C++ (and I have its full source). Due to its LGPL license I can only use it with the proprietary software of my company via dynamic linkage (static linkage works fine). So, I need to build it into a DLL. However, the library is quite big and doesn't export anything (hence no .def file and no __declspec(dllexport) statatements in front of the class and global function names). So, when I build a dll, it's useless, as it doesn't have exported names, so it won't link.
In our company we are using MS Visual C++, which by default does
not export names (while, for instance, GNU GCC, when run via MINGW on Windows does). So, the only option I see at the moment is placing __declspec(dllexport) in front of every name in the library that I'm using (and there are thousands), or writing a .def file for those names. But even if I did that, I will not be able to use the next version of the library,
as I'll have to do this job again. I was looking for a tool that does these exports, or generates a .map file, but none really do this specific task
(there are some DEF generators, but they mostly search the result of DUMPBIN /EXPORT which gives nothing in my case). I was searching the web for answers for two days now, but no good result.
Best regards,
Andriy
IANAL But if the library is LPGL they should be open to dynamic linking.
Have you considered modifying the source file and updating Makefile to give a way to generate the dynamic library and getting it approved by the maintainer ? Chances are they will be open to it and future versions will just work.
I don't think that there is such a automation you want.
My suggestion is editing the source code (as you said); using Notepad++'s macros or using Replace Pioneer
Regards
I have a few NT imports I want to use in my program, problem is I am unable to use them without going though the lengthly process of downloading and setting up the WDK to use just two functions. I would also prefer not to use GetModuleHandle and GetProcAddress.
I know in VB6 you can manually define imported functions from dlls like this:
Private Declare Function NtFunction Lib "ntdll.dll" (function arguments) As type
Is there something similar I can do with C++ in Visual Studio without having all the headers/libs?
You say you don't want to use GetProcAddress, but that's exactly what VB6 Declare Function (and .NET p/invoke) does.
You do need a complete prototype, often you can recreate enough of the header file from documentation.
The import library is a little more difficult, but there are tools to create import libraries from the .DLL.
If you create a .DEF file, you can use the LIB.EXE tool that comes with Visual C++ (and also available as a free download as part of the Windows SDK), see Building an Import Library
Here is some more information.
mingw comes with a tool for mostly automating creation of the .DEF file: http://www.mingw.org/wiki/CreateImportLibraries (the import library it creates is only usable with gcc, but the .DEF file is useful for making a VC++ import library as described above).
Here's a another tool that might help: http://www.codeproject.com/KB/tips/ImpDef.aspx
(I'm using Microsoft Visual Studio 2010 on a Windows 7 64 bit machine)
I have developed a C++ program that is more of a library which became quite complex over time. It does right now work as a simple executeable, but I'd like to convert it into a DLL so the functionality can be accessed by other programs easily.
I'm not at all experienced in working with DLLs, but I want to avoid much additional work and code changes in the process.
I know that I can select the compile target to "DLL", but I have the feeling that alone won't do the job.
If I successfully compiled my project into a DLL file, how do I use the functions in it from an executable project?
Can I avoid using _dllexport and importing every function per-name?
How does one statically link a DLL, and what are the (dis)advantages of this?
Honestly, I would take a look at the DLL export docs and pick whatever export method works best for you. In any case, you can simply reference exported functions by name from your client apps, as you would with a static library.
When you build the project as a DLL, the IDE will generate
The DLL file for runtime and
a LIB file containing exported function resolution information - that's the one you link against.
By definition, you cannot statically link a DLL (that's DYNAMIC link library) - instead, you link to a library that exports the functions from the DLL, and then the DLL loads at runtime, either automatically on process start or on demand. It's also possible to load the DLL completely on demand without any static linkage (see LoadLibraryEx etc).
Since you're using C++ I'm assuming you're exporting classes(?). There's a really good example over on CodeProject which walks you through a few options. The cleanest of which is to use an abstract interface:
A C++ abstract interface (i.e., a C++ class that contains only pure virtual methods and no data members) tries to get the best of both worlds: a compiler independent clean interface to an object, and a convenient object oriented way of method calls. All that is required to do is to provide a header file with an interface declaration and implement a factory function that will return the newly created object instances. Only the factory function has to be declared with the __declspec(dllexport/dllimport) specifier. The interface does not require any additional specifiers.
You can't statically link to a Dynamic Link Library. If you want to link statically, create a .lib instead.
To use your DLL you have to #include the header file(s) associated with your dll/lib and link with the .lib file that is associated with your .dll
You need the _declspec(dllexport)/_declspec(dllimport) to indicate you want to export/import the contents of the dll. This can be easily accomplished as follows
#ifdef FOO_EXPORTS
#define EXPORT_ME __declspec(dllexport)
#else
#define IMPORT_ME __declspec(dllimport)
#endif
in the headers for your dll you simply need to #define FOO_EXPORTS and place the EXPORT
foo.hpp
class EXPORT_ME foo2();
void EXPORT_ME foo_funct(foo2 *foo_ptr);
and any file that needs to use the exported items simply needs to call the the methods defined in the foo.hpp header (the default behavior is to import)
use_foo.cpp
main()
{
#include "foo.cpp";
foo2 myfoo;
foo_funct(&my_foo);
}
As others have said, a lib is statically linked and a dll is dynamically linked. Any referenced elements when linked statically are placed in-line at compile time into your source and generally produce a larger program (as far as file size), while dynamically linked elements are linked in at run-time so the file size is usually smaller. There are many other pros/cons to static vs dynamic - I recommend you follow Doc Browns link for more info
Switch to gcc under MinGW. Building and linking to a DLL is just as easy as building and linking to a static library. It even handles C++ name mangling transparently (but then the calling program also needs to be compiled with gcc).
I know this may seem quite basic to geeks. But I want to make it crystal clear.
When I want to use a Win32 DLL, usually I just call the APIs like LoadLibrary() and GetProcAdderss(). But recently, I am developing with DirectX9, and I need to add d3d9.lib, d3dx9.lib, etc files.
I have heard enough that LIB is for static linking and DLL is for dynamic linking.
So my current understanding is that LIB contains the implementation of the methods and is statically linked at link time as part of the final EXE file. While DLL is dynamic loaded at runtime and is not part of the final EXE file.
But sometimes, there're some LIB files coming with the DLL files, so:
What are these LIB files for?
How do they achieve what they are meant for?
Is there any tools that can let me inspect the internals of these LIB files?
Update 1
After checking wikipedia, I remember that these LIB files are called import library.
But I am wondering how it works with my main application and the DLLs to be dynamically loaded.
Update 2
Just as RBerteig said, there're some stub code in the LIB files born with the DLLs. So the calling sequence should be like this:
My main application --> stub in the LIB --> real target DLL
So what information should be contained in these LIBs? I could think of the following:
The LIB file should contain the fullpath of the corresponding DLL; So the DLL could be loaded by the runtime.
The relative address (or file offset?) of each DLL export method's entry point should be encoded in the stub; So correct jumps/method calls could be made.
Am I right on this? Is there something more?
BTW: Is there any tool that can inspect an import library? If I can see it, there'll be no more doubts.
Linking to a DLL file can occur implicitly at compile link time, or explicitly at run time. Either way, the DLL ends up loaded into the processes memory space, and all of its exported entry points are available to the application.
If used explicitly at run time, you use LoadLibrary() and GetProcAddress() to manually load the DLL and get pointers to the functions you need to call.
If linked implicitly when the program is built, then stubs for each DLL export used by the program get linked in to the program from an import library, and those stubs get updated as the EXE and the DLL are loaded when the process launches. (Yes, I've simplified more than a little here...)
Those stubs need to come from somewhere, and in the Microsoft tool chain they come from a special form of .LIB file called an import library. The required .LIB is usually built at the same time as the DLL, and contains a stub for each function exported from the DLL.
Confusingly, a static version of the same library would also be shipped as a .LIB file. There is no trivial way to tell them apart, except that LIBs that are import libraries for DLLs will usually be smaller (often much smaller) than the matching static LIB would be.
If you use the GCC toolchain, incidentally, you don't actually need import libraries to match your DLLs. The version of the Gnu linker ported to Windows understands DLLs directly, and can synthesize most any required stubs on the fly.
Update
If you just can't resist knowing where all the nuts and bolts really are and what is really going on, there is always something at MSDN to help. Matt Pietrek's article An In-Depth Look into the Win32 Portable Executable File Format is a very complete overview of the format of the EXE file and how it gets loaded and run. Its even been updated to cover .NET and more since it originally appeared in MSDN Magazine ca. 2002.
Also, it can be helpful to know how to learn exactly what DLLs are used by a program. The tool for that is Dependency Walker, aka depends.exe. A version of it is included with Visual Studio, but the latest version is available from its author at http://www.dependencywalker.com/. It can identify all of the DLLs that were specified at link time (both early load and delay load) and it can also run the program and watch for any additional DLLs it loads at run time.
Update 2
I've reworded some of the earlier text to clarify it on re-reading, and to use the terms of art implicit and explicit linking for consistency with MSDN.
So, we have three ways that library functions might be made available to be used by a program. The obvious follow up question is then: "How to I choose which way?"
Static linking is how the bulk of the program itself is linked. All of your object files are listed, and get collected together in to the EXE file by the linker. Along the way, the linker takes care of minor chores like fixing up references to global symbols so that your modules can call each other's functions. Libraries can also be statically linked. The object files that make up the library are collected together by a librarian in a .LIB file which the linker searches for modules containing symbols that are needed. One effect of static linking is that only those modules from the library that are used by the program are linked to it; other modules are ignored. For instance, the traditional C math library includes many trigonometry functions. But if you link against it and use cos(), you don't end up with a copy of the code for sin() or tan() unless you also called those functions. For large libraries with a rich set of features, this selective inclusion of modules is important. On many platforms such as embedded systems, the total size of code available for use in the library can be large compared to the space available to store an executable in the device. Without selective inclusion, it would be harder to manage the details of building programs for those platforms.
However, having a copy of the same library in every program running creates a burden on a system that normally runs lots of processes. With the right kind of virtual memory system, pages of memory that have identical content need only exist once in the system, but can be used by many processes. This creates a benefit for increasing the chances that the pages containing code are likely to be identical to some page in as many other running processes as possible. But, if programs statically link to the runtime library, then each has a different mix of functions each laid out in that processes memory map at different locations, and there aren't many sharable code pages unless it is a program that all by itself is run in more than process. So the idea of a DLL gained another, major, advantage.
A DLL for a library contains all of its functions, ready for use by any client program. If many programs load that DLL, they can all share its code pages. Everybody wins. (Well, until you update a DLL with new version, but that isn't part of this story. Google DLL Hell for that side of the tale.)
So the first big choice to make when planning a new project is between dynamic and static linkage. With static linkage, you have fewer files to install, and you are immune from third parties updating a DLL you use. However, your program is larger, and it isn't quite as good citizen of the Windows ecosystem. With dynamic linkage, you have more files to install, you might have issues with a third party updating a DLL you use, but you are generally being friendlier to other processes on the system.
A big advantage of a DLL is that it can be loaded and used without recompiling or even relinking the main program. This can allow a third party library provider (think Microsoft and the C runtime, for example) to fix a bug in their library and distribute it. Once an end user installs the updated DLL, they immediately get the benefit of that bug fix in all programs that use that DLL. (Unless it breaks things. See DLL Hell.)
The other advantage comes from the distinction between implicit and explicit loading. If you go to the extra effort of explicit loading, then the DLL might not even have existed when the program was written and published. This allows for extension mechanisms that can discover and load plugins, for instance.
These .LIB import library files are used in the following project property, Linker->Input->Additional Dependencies, when building a bunch of dll's that need additional information at link time which is supplied by the import library .LIB files. In the example below to not get linker errors I need to reference to dll's A,B,C, and D through their lib files. (note for the linker to find these files you may need to include their deployment path in Linker->General->Additional Library Directories else you will get a build error about being unable to find any of the provided lib files.)
If your solution is building all dynamic libraries you may have been able to avoid this explicit dependency specification by relying instead on the reference flags exposed under the Common Properties->Framework and References dialog. These flags appear to automatically do the linking on your behalf using the *.lib files.
This however is as it says a Common Properties, which is not configuration or platform specific. If you need to support a mixed build scenario as in our application we had a build configuration to render a static build and a special configuration that built a constrained build of a subset of assemblies that were deployed as dynamic libraries. I had used the Use Library Dependency Inputs and Link Library Dependencies flags set to true under various cases to get things to build and later realizing to simplify things but when introducing my code to the static builds I introduced a ton of linker warnings and the build was incredibly slow for the static builds. I wound up introducing a bunch of these sort of warnings...
warning LNK4006: "bool __cdecl XXX::YYY() already defined in CoreLibrary.lib(JSource.obj); second definition ignored D.lib(JSource.obj)
And I wound up using the manual specification of Additional Dependencies to satisfy the linker for the dynamic builds while keeping the static builders happy by not using a common property that slowed them down. When I deploy the dynamic subset build I only deploy the dll files as these lib files are only used at link time, not at runtime.
Here are some related MSDN topics to answer my question:
Linking an Executable to a DLL
Linking Implicitly
Determining Which Linking Method to Use
Building an Import Library and Export File
There are three kinds of libraries: static, shared and dynamically loaded libraries.
The static libraries are linked with the code at the linking phase, so they are actually in the executable, unlike the shared library, which has only stubs (symbols) to look for in the shared library file, which is loaded at run time before the main function gets called.
The dynamically loaded ones are much like the shared libraries, except they are loaded when and if the need arises by the code you've written.
In my mind, there are two method to link dll to exe.
Use dll and the import library (.lib file) implicitly
Use functions like loadlibrary() explicitly