3.10. Динамические библиотеки

В Windows и OS/2 используется именно такой способ загрузки. Исполняе­мый модуль в этих системах содержит ссылки на другие модули, называе­мые DLL (Dynamically Loadable Library, динамически загружаемая библиоте­ка). Фактически, каждый модуль в этих системах обязан содержать хотя бы одну ссылку на DLL, потому что интерфейс к системным вызовам в этих ОС также реализован в виде DLL.

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

Главное достоинство DLL состоит в том, что модуль (как основной, так и библиотечный), по собственному желанию, может выбирать различные биб­лиотеки, подгружая их уже после своей собственной загрузки. При этом нет даже строгого ограничения на совместимость этих библиотек по вызовам (две библиотеки совместимы по вызовам, если они имеют одинаковые точки входа с одинаковой семантикой): загрузчик предоставляет возможность просмотреть список глобальных символов, определенных в библиотеке и получить указатель на каждый символ, обратившись к нему по имени; (впрочем, количество и типы параметров или тип переменной, а тем более их семантику, загрузчик не сообщает - эту информацию надо получать из других источников, например из списка зарегистрированных в системе объектов СОМ).

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

Другая проблема, обусловленная широким использованием разделяемого кода, состоит в слежении за версией этого кода.

Разделяемый код в системах семейства Windows

Катастрофические масштабы эта проблема принимает в системах семей­ства Windows, где принято помещать в дистрибутивы прикладных программ все потенциально разделяемые модули, которые этой программе могут по­требоваться — среда исполнения компилятора и т. д. При этом каждое приложение считает своим долгом поместить свои разделяемые модули в C:\WINDOWS\SYSTEM32 (в Windows NT/2000/XP это заодно приводит к тому, что установка самой безобидной утилиты требует администраторских привиле­гий). Средств же проследить за тем, кто, какую версию, чего, куда и зачем по­ложил, практически не предоставляется.

В лучшем случае установочная программа спрашивает: "Тут вот у вас что-то уже лежит, перезаписать?". Стандартный деинсталлятор содержит список DLL, которые принадлежат данному приложению, и осознает тот факт, что эти же DLL используются кем-то еще, но не предоставляет (и, по-видимому, не пыта­ется собрать) информации о том, кем именно они используются. Наличие рее­стра объектов СОМ не решает проблемы, потому что большая часть приноси­мого каждым приложением "разделяемого" кода (кавычки стоят потому, что значительная часть этого кода никому другому, кроме принесшего его прило­жения, не нужна) не является сервером СОМ.

В результате, когда, например, после установки MS Project 2000 перестает ра­ботать MS Office 2000, это никого не удивляет, а конфликты между приложениями различных разработчиков или разных "поколений" счи­таются неизбежными. Установить же в одной системе и использовать хотя бы попеременно две различные версии одного продукта просто невозможно — од­нако, когда каждая версия продукта использует собственный формат данных, а конверсия между ними неидеальна, это часто оказывается желательно. Разработчики же и тестеры, которым надо обеспечить совместимость с различными версиями существующих приложений, при этом просто оказываются в безвыходной ситуации. Неслучайно поставщики VmWare (системы виртуальных машин для х86) как одно из главных достоинств своей системы рекламируют возможность держать несколько копий Windows одновременно загруженными на одной машине.

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