Как работает библиотека импорта? Подробности?

Связывание с файлом DLL может происходить неявно во время компиляции или явно во время выполнения. В любом случае DLL загружается в пространство памяти процессов, и все ее экспортированные точки входа становятся доступными для приложения.

При явном использовании во время выполнения вы используете LoadLibrary() и GetProcAddress(), чтобы вручную загрузить DLL и получить указатели на функции, которые необходимо вызвать.

При неявной компоновке при сборке программы заглушки для каждого экспорта DLL, используемого программой, связываются с программой из библиотеки импорта, и эти заглушки обновляются по мере загрузки EXE и DLL при запуске процесса. . (Да, здесь я несколько упростил...)

Эти заглушки должны откуда-то браться, а в цепочке инструментов Microsoft они берутся из особой формы файла .LIB, называемой библиотекой импорта. . Требуемый .LIB обычно создается одновременно с DLL и содержит заглушку для каждой функции, экспортируемой из DLL.

Как ни странно, статическая версия той же библиотеки также будет поставляться в виде файла .LIB.Не существует тривиального способа отличить их друг от друга, за исключением того, что LIB, которые являются библиотеками импорта для DLL, обычно меньше (часто намного меньше), чем соответствующие статические LIB.

Между прочим, если вы используете набор инструментов GCC, вам фактически не нужны библиотеки импорта для соответствия вашим библиотекам DLL. Версия компоновщика Gnu, перенесенная на Windows, понимает библиотеки DLL напрямую и может синтезировать большинство необходимых заглушек на лету.

Обновление

Если вы просто не можете удержаться от того, чтобы не узнать, где на самом деле все гайки и болты и что происходит на самом деле, на MSDN всегда есть чем помочь. Статья Мэтта Питрека An In-Depth Look in the Win32 Portable Executable File Format представляет собой очень полный обзор формата EXE-файла и того, как он загружается и запускается. Он даже был обновлен, чтобы охватывать .NET и многое другое, поскольку он первоначально появился в журнале MSDN Magazine ок. 2002.

Кроме того, может быть полезно знать, как узнать, какие именно библиотеки DLL используются программой. Инструментом для этого является Dependency Walker, также известный как depend.exe. Его версия включена в Visual Studio, но последнюю версию можно получить у автора по адресу http://www.dependencywalker.com/. Он может идентифицировать все библиотеки DLL, указанные во время компоновки (как с ранней загрузкой, так и с отложенной загрузкой), а также может запускать программу и отслеживать любые дополнительные библиотеки DLL, которые она загружает во время выполнения.

Обновление 2.

Я переформулировал часть предыдущего текста, чтобы уточнить его при повторном прочтении и использовать термины искусства неявные и явные ссылки для единообразия. с MSDN.

Итак, у нас есть три способа сделать библиотечные функции доступными для использования программой. Очевидный последующий вопрос звучит так: «Как мне выбрать, какой путь?»

Статическое связывание — это то, как связывается большая часть самой программы. Все ваши объектные файлы перечислены и собраны компоновщиком в EXE-файл. Попутно компоновщик берет на себя мелкие хлопоты, такие как исправление ссылок на глобальные символы, чтобы ваши модули могли вызывать функции друг друга. Библиотеки также могут быть статически связаны. Объектные файлы, составляющие библиотеку, собираются библиотекарем в файле .LIB, в котором компоновщик ищет модули, содержащие необходимые символы. Одним из эффектов статической компоновки является то, что с ней компонуются только те модули из библиотеки, которые используются программой; другие модули игнорируются. Например, традиционная математическая библиотека C включает множество функций тригонометрии. Но если вы свяжетесь с ним и используете cos(), вы не получите копию кода для sin() или tan() если вы также не вызвали эти функции. Для больших библиотек с богатым набором функций такое выборочное включение модулей важно. На многих платформах, таких как встроенные системы, общий размер кода, доступного для использования в библиотеке, может быть большим по сравнению с пространством, доступным для хранения исполняемого файла на устройстве. Без выборочного включения было бы сложнее управлять деталями создания программ для этих платформ.

Однако наличие копии одной и той же библиотеки в каждой запущенной программе создает нагрузку на систему, в которой обычно выполняется множество процессов. При правильном типе системы виртуальной памяти страницы памяти с идентичным содержимым должны существовать в системе только один раз, но могут использоваться многими процессами.Это создает преимущество для увеличения вероятности того, что страницы, содержащие код, вероятно, будут идентичны какой-либо странице в как можно большем количестве других запущенных процессов. Но если программы статически связаны с библиотекой времени выполнения, то каждая из них имеет различный набор функций, каждая из которых размещена в этой карте памяти процессов в разных местах, и не так много общих кодовых страниц, если только это не программа, которая сама по себе запускать больше, чем процесс. Таким образом, идея DLL получила еще одно важное преимущество.

DLL для библиотеки содержит все ее функции, готовые к использованию любой клиентской программой. Если многие программы загружают эту DLL, все они могут совместно использовать ее кодовые страницы. Все выигрывают. (Ну, до тех пор, пока вы не обновите DLL новой версией, но это не является частью этой истории. Google DLL — к черту эту сторону истории.)

Итак, первый большой выбор, который нужно сделать при планировании нового проекта, — это между динамическая и статическая связь. При статической компоновке вам нужно установить меньше файлов, и вы защищены от третьих лиц, обновляющих используемую вами DLL. Однако ваша программа больше, и она не так хороша для экосистемы Windows. С динамической компоновкой вам нужно установить больше файлов, у вас могут возникнуть проблемы с обновлением третьей стороной используемой вами библиотеки DLL, но вы, как правило, более дружелюбны к другим процессам в системе.

Большим преимуществом DLL является то, что ее можно загружать и использовать без перекомпиляции или даже повторной компоновки основной программы. Это может позволить стороннему поставщику библиотек (например, Microsoft и среда выполнения C) исправить ошибку в своей библиотеке и распространить ее.Как только конечный пользователь установит обновленную библиотеку DLL, он сразу же получит преимущество исправления ошибки во всех программах, использующих эту библиотеку DLL. (Если только это ничего не ломает. См. DLL Hell.)

Другое преимущество связано с различием между неявной и явной загрузкой. Если вы приложите дополнительные усилия для явной загрузки, то DLL может даже не существовать, когда программа была написана и опубликована. Это позволяет использовать механизмы расширения, которые могут, например, обнаруживать и загружать плагины.