为什么 LIB 文件具有如此两面性的野兽？
我正在尝试了解 Microsoft Windows 上的 LIB 文件业务，并且我刚刚有了一个发现，我希望它能够消除迄今为止阻止我清楚掌握该问题的困惑。也就是说，LIB 文件并不是其文件扩展名所表明的那种文件。
:: 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
前两个示例包含目标文件（由 lib.exe 实用程序显示时显示为相对或绝对路径）。然而，第三个示例仅包含 731 个对 DLL 的引用。 （我猜 lib.exe 并不是为了显示此类文件的更多有用信息而设计的。）
有些包含目标文件，并且它们是静态库。其他包含符号，它们是导入库。 （这里有一个简短说明。）
因此静态库似乎相当于.a 文件，DLL 似乎映射到 Linux 上的 .so 文件。 （顺便问一下，导入库如何适应这个 Windows/Linux 等效图？）
现在我想知道为什么会这样？为什么 Microsoft 决定为导入库提供与静态库相同的文件扩展名？ （我知道，从历史上看，静态库是第一位的，就像生命的原始形式先于更复杂的形式一样。）为什么他们不说，好吧，这是这些新型库，它们将被称为导入库，并且它们将带有文件扩展名.ILB（或其他）？
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)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因为它们是图书馆。为什么要发明一个全新的特定于供应商的扩展，因为它与已经特定于供应商的库完全相同？
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?