72

I'm trying to understand this LIB file business on Microsoft Windows, and I've just made a discovery that will - I hope - dispel the confusion that hitherto has prevented me from getting a clear grasp of the issue. To wit, LIB files are not the one kind of file that their file extension suggests they are.

:: cd "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib"

:: lib /nologo /list Ad1.Lib
obj\i386\activdbgid.obj
obj\i386\activscpid.obj
obj\i386\ad1exid.obj
obj\i386\dbgpropid.obj
obj\i386\dispexid.obj

:: lib /nologo /list oledb.lib
o:\winmain.obj.x86fre\enduser\…\oledb\uuid\objfre\i386\oledbiid.obj
o:\winmain.obj.x86fre\enduser\…\oledb\uuid\objfre\i386\oledbnewiid.obj
o:\winmain.obj.x86fre\enduser\…\oledb\uuid\objfre\i386\cmdtreeiid.obj
o:\winmain.obj.x86fre\enduser\…\oledb\uuid\objfre\i386\oledbdepiid.obj

:: lib /nologo /list AdvAPI32.Lib | sort | uniq -c
    731 ADVAPI32.dll

The first two examples contain object files (appearing as relative or absolute paths when displayed by the lib.exe utility). The third example, however, only contains 731 references to a DLL. (I guess lib.exe isn't designed to display more useful information for this kind of file.)

Some contain object files, and they are static libraries. Others contain symbols, and they are import libraries. (There's a short explanation here.)

So static libraries appear to be the equivalents of .a files on Linux, and DLLs appear to map to .so files on Linux. (By the way, how would import libraries fit into this Windows/Linux equivalence picture?)

Now I'm wondering why this is so? Why did Microsoft decide to give import libraries the same file extension as static libraries? (I understand that historically, static libraries were first, like primitive forms of life preceded more complex forms.) Why wouldn't they say, okay, here's these new kind of libraries, they shall be referred to as import libraries, and they shall bear the file extension .ILB (or whatever)?

Community
  • 1
  • 1
Lumi
  • 14,775
  • 8
  • 59
  • 92
  • 6
    From the [CMake FAQ](http://www.cmake.org/Wiki/CMake_FAQ#Why_does_FIND_LIBRARY_not_find_.DLL_libraries_under_WIN32.3F): "In Windows, there are two types of library, a static library and an import library (both confusingly use the .lib extension, however)." So I was not alone in being confused about this. – Lumi Jul 02 '11 at 18:50
  • 6
    BTW, [MinGW/GCC supports linking directly against the DLL](http://sources.redhat.com/binutils/docs-2.21/ld/WIN32.html): "The cygwin/mingw ports of ld support the direct linking, including data symbols, to a dll without the usage of any import libraries. This is much faster and uses much less memory than does the traditional import library method, especially when linking large libraries or applications. ... Linking directly to a dll uses no extra command-line switches other than `-L' and `-l' ... one might justifiably wonder why import libraries are used at all. There are three reasons: ..." – Lumi Jul 02 '11 at 19:00
  • 5
    As far as I understood, on windows it's not like on linux. You _always_ link to a .lib. This .lib can contain either the library code, _or_ a stub that loads the dll and runs it from there. So you are always, in a sense, linking statically a .lib. It's just that when you link dynamically, the .lib contains just the stub, and the actual code is stored in the dll. – Stefano Borini Jan 26 '15 at 10:21
  • @Lumi I'm also curious what is the benefit of Import Libraries don't you know? PS: the lib utility that you've used, where can be obtained from? Thanks. – Wakan Tanka Sep 08 '16 at 23:07
  • @WakanTanka, [`LIB.EXE` is part of Visual Studio](https://msdn.microsoft.com/de-de/library/7ykb2k5f.aspx). As for the benefit of Import Libraries, well, they implement dynamic linking, so they do the job. :) Stefano Borini's comment above explains how they work in a concise fashion. – Lumi Sep 18 '16 at 20:11

1 Answers1

10

Because they are libraries. Why invent a whole new vendor-specific extension for what is exactly the same thing as their already-vendor-specific libraries?

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • 20
    Hmm, but DLLs are also libraries, which did not hinder MS from endowing them with a dedicated `.dll` extension. But, I hear you say, they are different beasts. Well, but what then about **static** libraries (containing code) and **import** libraries (containing pointers to code)? What's so similar about them that it was practical to give them the same name? And why are import libraries needed for code to be bound against DLLs when Linux does not require any? Maybe these questions appear stupid when you've known that stuff for ages, but if you're new to it, I think you have reason to wonder. – Lumi Jun 21 '11 at 17:29
  • 15
    That's what I'm talking about, static and import libraries. Import libraries aren't anything magical, certainly not "pointers to code", they contain normal code calling `LoadLibrary` and `GetProcAddress` to load the function pointers for you. – Blindy Jun 21 '11 at 18:49
  • 1
    And the difference between DLL's and libraries is that DLL's are completely compiled and can be used as is by *anything* at runtime, whereas libraries can only be used by the linker that came with the compiler that made them (they are vendor-specific) and only at compile time. – Blindy Jun 21 '11 at 18:50
  • 22
    Thanks - I got it! Import libraries are normal libraries, that's the point, libraries that are statically linked, containing only the code to dynamically load the actual code in the DLL. This is also briefly explained in the [MSDN docs for the `cl.exe /MD` option](http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx). – Lumi Jun 22 '11 at 22:26
  • `lib` files are windows OS thing. So I wouldn't wonder why. – Vassilis Mar 08 '23 at 10:15
  • @Vassilis, *you* personally could stand to wonder why, because `lib` files have nothing to do with the OS. Only Linux ties its compilers to the kernel through `.so` files that both consume and both have to have identical versions of dependencies to function. – Blindy Mar 08 '23 at 15:06
  • @Blindy, Yes, you're right I meant windows-specific not "windows OS". `lib` files seem to be windows specific and there are two kinds of them plus the `.dll`s for dynamic libraries. This is discussed already, thus the frustration. On linux `.so` and `.a` is used and on MacOS `.dynlyb` and `.a` is used, for dynamic and static libraries. Have you ever came across with `lib` libraries on linux or MacOS? – Vassilis Mar 11 '23 at 10:24
  • You're still missing the point, there is nothing OS-specific about `.lib` files, it just so happens that it nobody uses the format on Linux. Nothing is stopping you from doing so, besides the fact that making compilers is hard. Contrast that with Linux's `.so` and `.a` are required for the kernel to even run. Also contrast them with `.dll` files on Windows, which are required for Windows' kernel to run, but are not compiler inputs -- just outputs. Does that help clear things up? – Blindy Mar 11 '23 at 17:33