1

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

  • Having to keep the .def file in sync with your code is very little joy. If you don't have to rename the export, you never *really* do, then the declspec is mighty convenient. Keep in mind that you can still use #pragma comment to inject the linker's /export directive. – Hans Passant Mar 07 '18 at 17:27
  • I don't know why this article is so focused on export by ordinal, which no one is using anyway (except MSFT). IMO the more important advantage of .def file is that you can export functions by unmangled name, which makes it easier to link DLL from other language than it was written in. – zett42 Mar 07 '18 at 17:55
  • @zett42 I don't understand why we have to recompile our app if we update a dll wasn't it the main objective to shared library to don't have to do that ? –  Mar 07 '18 at 18:02
  • Rebuilding the app shouldn't be necessary if you only add a new function and existing functions stay backwards compatible. I don't really see the point of that part of the article as you have to use a .def file in the first place to export by ordinal. With `__declspec(dllexport)` functions are exported by name by default. – zett42 Mar 07 '18 at 18:17
  • I agree with you @zett42 after some some tests i can add new exported functions to my dll and my exe still working. But people still saying that you have to relink i still dont understand why –  Mar 07 '18 at 19:24
  • If this would really be the case, all existing applications would stop working when a new version of Windows comes out or when MSFT adds new functions through a Windows update, which also happens quite often. – zett42 Mar 07 '18 at 20:01

2 Answers2

1

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.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • Great answer ! I thought that the main advantage of the dll was that we can change them without touch the main app. So it's not the case infact we have to relink the app with the dll ? Is it the method generally used by software developers ? And when we use the other method declspec does it use cardinal number under the hood too ? –  Mar 07 '18 at 17:45
  • @Rain-io, you can change the implementation of already available functions, but you can't add more functions. – SergeyA Mar 07 '18 at 19:07
  • Thanks but i dont understand after some tests using declspec i can add new exported functions into the dll and the app main still working without a new linking. Is there something that i forget ? –  Mar 07 '18 at 19:21
  • @Rain-io it is not guaranteed to be working. The ordinals might change, might remain the same. – SergeyA Mar 07 '18 at 19:26
  • Are you sure about that (some sources?) i thought that with declspec it use the function naming to find them, are you sure that even with declspec it use ordinal numbers ? We can create an import lib from a .def wich we have create manualy after the dll has been compiled. And this .def has only function name mentioned, not number, we use the lib create to build our exe and it works, the exe find dll function with only the names. That's why i'm little confuse. (im not the downvoter) –  Mar 07 '18 at 19:39
  • I have my answer here https://stackoverflow.com/questions/49160234/rebuild-exe-after-dll-updated?noredirect=1#comment85325873_49160234 Thanks @SergeyA –  Mar 07 '18 at 20:05
  • `.lib` here has nothing to do with static library Not more than a same extension – Алексей Неудачин Nov 08 '21 at 14:43
0

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.

Victor Gubin
  • 2,782
  • 10
  • 24
  • I'm fairly certain the import library gets created for any DLL regardless if the author is using .def files to export or not. Using `__declspec dllexport` to export function should result in an import .lib file being generated as well. – selbie Mar 07 '18 at 17:33
  • .def file can be created even manually or extracted from DLL import section by some tool. What if you've created your DLL using assembly and need an import library in order to use it in C without LoadLibrary ? – Victor Gubin Mar 07 '18 at 17:38
  • What use is a .def file after the DLL has already been built? – selbie Mar 07 '18 at 17:39
  • Yes, for example with GNU DLL tool http://mirrors.zoreil.com/webclub.kcom.ne.jp/ma/colinp/win32/tools/dlltool.html like this impdef foobar.dll >foobar.def – Victor Gubin Mar 07 '18 at 17:55
  • Once you have recovered a .def file, what would you do with it? I suppose it enables you to create a compatible drop-in replacement DLL... – selbie Mar 07 '18 at 18:02
  • It will allow you to create an import library. For example you've using MinGW (GCC for Windows) and d'like to use a DLL build by MS VC++ or vise versa. So if you have a .def file you can create such an import library. Otherwise - you will have to deal with LoadLibrary and taking function addresses from DLL export section manually. – Victor Gubin Mar 07 '18 at 18:16