Я пытаюсь понять этот бизнес, связанный с файлами LIB в Microsoft Windows, и я только что сделал открытие, которое, надеюсь, рассеет путаницу, которая до сих пор мешала мне получить четкое представление о проблеме.Иными словами, файлы 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 в Linux, а библиотеки DLL отображаются в файлы .so в Linux.(Кстати, как библиотеки импорта вписались бы в эту картину эквивалентности Windows / Linux?)
Теперь мне интересно, почему это так?Почему Microsoft решила предоставить библиотекам импорта то же расширение файла, что и статическим библиотекам?(Я понимаю, что исторически статические библиотеки были первыми, как примитивные формы жизни предшествовали более сложным формам.) Почему бы им не сказать, хорошо, вот эти новые виды библиотек, их следует называть библиотеками импорта, и они должнынести расширение файла .ILB (или как там)?