Библиотека динамической компоновки dll. Работа с библиотеками динамической компоновки (DLL). Библиотеки динамической компоновки – DLL. COM-модель и COM-объекты

Библиотеки динамической компоновки (DLL)

DLL (англ. Dynamic Link Library -- «библиотека динамической компоновки», «динамически подключаемая библиотека») в операционных системах Microsoft Windows и IBM OS/2 -- динамическая библиотека, позволяющая многократное использование различными программными приложениями. K DLL относятся также элементы управления ActiveX и драйверы. В мире UNIX аналогичные функции выполняют так называемые общие объекты.

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

Библиотеки динамической компоновки также имеют способность обеспечивать обмен данными между процессами. Когда в рамках DLL объявляется переменная, ее можно сделать разделяемой (shared). Все процессы, обращающиеся к библиотеке, для таких переменных будут использовать одно и то же место в физической памяти. (Здесь также важно не забыть о синхронизации.)

Протокол динамического обмена данными (Dynamic Data Exchange, DDE)

Этот протокол выполняет все основные функции для обмена данными между приложениями. Он очень широко использовался до тех пор, пока для этих целей не стали применять OLE (впоследствии ActiveX). На данный момент DDE используется достаточно редко, в основном для обратной совместимости.

Больше всего этот протокол подходит для задач, не требующих продолжительного взаимодействия с пользователем. Пользователю в некоторых случаях нужно только установить соединение между программами, а обмен данными происходит без его участия. Замечу, что все это в равной степени относится и к технологии OLE/ActiveX.

OLE/ActiveX

OLE (англ. Object Linking and Embedding)-- технология связывания и внедрения объектов в другие документы и объекты, разработанная корпорацией Майкрософт.

В 1996 году Microsoft переименовала технологию в ActiveX.

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

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

OLE используется при обработке составных документов, может быть использована при передаче данных между различными несвязанными между собой системами посредством интерфейса переноса, а также при выполнении операций с буфером обмена. Идея внедрения широко используется при работе с мультимедийным содержанием на веб-страницах, где используется передача изображения, звука, видео, анимации в страницах HTML либо в других файлах, также использующих текстовую разметку (например, XML и SGML). Однако, технология OLE использует архитектуру «толстого клиента», то есть сетевой ПК с избыточными вычислительными ресурсами. Это означает, что тип файла либо программа, которую пытаются внедрить, должна присутствовать на машине клиента. Например, если OLE оперирует таблицами Microsoft Excel, то программа Excel должна быть инсталлирована на машине пользователя.

В 1996 году Microsoft переименовала технологию OLE 2.0 в ActiveX. Были представлены элементы управления ActiveX, ActiveX документы и технология Active Scripting. Эта версия OLE в основном используется веб-дизайнерами для вставки в страницы мультимедийных данных.

Это действительно универсальная технология, и одно из многих ее применений - межпроцессный обмен данными. Хотя, стоит отметить, что OLE как раз для этой цели и создавалась (на смену DDE), и только потом была расширена. Специально для обмена данными существует интерфейс IDataObject. А для обмена данными по сети используется DCOM, которую под некоторым углом можно рассматривать как объединение ActiveX и RPC.

Каналы (pipes)

В среде операционной системы Microsoft Windows NT вам доступно такое удобное средство передачи данных между параллельно работающими процессами, как каналы типа Pipe. Это средство позволяет организовать передачу данных между локальными процессами, а также между процессами, запущенными на различных рабочих станциях в сети.

Каналы типа Pipe больше всего похожи на файлы, поэтому они достаточно просты в использовании.

Через канал можно передавать данные только между двумя процессами. Один из процессов создает канал, другой открывает его. После этого оба процесса могут передавать данные через канал в одну или обе стороны, используя для этого хорошо знакомые вам функции, предназначенные для работы с файлами, такие как ReadFile и WriteFile. Заметим, что приложения могут выполнять над каналами Pipe синхронные или асинхронные операции, аналогично тому, как это можно делать с файлами. В случае использования асинхронных операций необходимо отдельно побеспокоиться об организации синхронизации.

Каналы - это очень мощная технология обмена данными. Наверное, именно поэтому в полной мере они поддерживаются только в Windows NT/2000. В общем случае канал можно представить в виде трубы, соединяющей два процесса. Что попадает в трубу на одном конце, мгновенно появляется на другом. Чаще всего каналы используются для передачи непрерывного потока данных.

Именованные и анонимные каналы

Существуют две разновидности каналов Pipe - именованные (Named Pipes) и анонимные (Anonymous Pipes).

Как видно из названия, именованным каналам при создании присваивается имя, которое доступно для других процессов. Зная имя какой-либо рабочей станции в сети, процесс может получить доступ к каналу, созданному на этой рабочей станции.

Анонимные каналы обычно используются для организации передачи данных между родительскими и дочерними процессами, запущенными на одной рабочей станции или на “отдельно стоящем” компьютере.

Анонимные каналы используются достаточно редко, они просто передают поток вывода одного процесса на поток ввода другого. Именованные каналы передают произвольные данные и могут работать через сеть. (Именованные каналы поддерживаются только в WinNT/2000.)

Сокеты (sockets)

Сокеты (англ. socket -- разъём) -- название программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на одной ЭВМ, так и на различных ЭВМ, связанных между собой сетью. Сокет -- абстрактный объект, представляющий конечную точку соединения.

Следует различать клиентские и серверные сокеты. Клиентские сокеты грубо можно сравнить с оконечными аппаратами телефонной сети, а серверные -- с коммутаторами. Клиентское приложение (например, браузер) использует только клиентские сокеты, а серверное (например, веб-сервер, которому браузер посылает запросы) -- как клиентские, так и серверные сокеты.

Интерфейс сокетов впервые появился в BSD Unix. Программный интерфейс сокетов описан в стандарте POSIX.1 и в той или иной мере поддерживается всеми современными операционными системами.

приложение память межпроцессный сокет

Принципы сокетов

Каждый процесс может создать слушающий сокет (серверный сокет) и привязать его к какому-нибудь порту операционной системы (в UNIX непривилегированные процессы не могут использовать порты меньше 1024). Слушающий процесс обычно находится в цикле ожидания, то есть просыпается при появлении нового соединения. При этом сохраняется возможность проверить наличие соединений на данный момент, установить тайм-аут для операции и т.д.

Каждый сокет имеет свой адрес. ОС семейства UNIX могут поддерживать много типов адресов, но обязательными являются INET-адрес и UNIX-адрес. Если привязать сокет к UNIX-адресу, то будет создан специальный файл по заданному пути, через который смогут сообщаться любые локальные процессы путём чтения/записи из него (см. Доменный сокет Unix). Сокеты типа INET доступны из сети и требуют выделения номера порта.

Обычно клиент явно подсоединяется к слушателю, после чего любое чтение или запись через его файловый дескриптор будут передавать данные между ним и сервером.

Это очень важная технология, т.к. именно она отвечает за обмен данными в Интернет. Сокеты также часто используются в крупных ЛВС. Взаимодействие происходит через т.н. разъемы-"сокеты", которые представляют собой абстракцию конечных точек коммуникационной линии, соединяющей два приложения. С этими объектами программа и должна работать, например, ждать соединения, посылать данные и т.д. В Windows входит достаточно мощный API для работы с сокетами.

Почтовые слоты (mailslots)

Почтовые слоты - это механизм однонаправленного IPC. Если приложению известно имя слота, оно может помещать туда сообщения, а приложение-хозяин этого слота (приемник) может их оттуда извлекать и соответствующим образом обрабатывать. Основное преимущество этого способа - возможность передавать сообщения по локальной сети сразу нескольким компьютерам за одну операцию. Для этого приложения-приемники создают почтовые слоты с одним и тем же именем. Когда в дальнейшем какое-либо приложение помещает сообщение в этот слот, приложения-приемники получают его одновременно.

Объекты синхронизации

Как ни странно, объекты синхронизации тоже можно отнести к механизмам IPC. Конечно, объем передаваемых данных в данном случае очень невелик. Но именно эти объекты следует использовать, если одному процессу нужно передать другому что-то вроде "я закончил работу" или "я начинаю работать с общей памятью".

Microsoft Message Queue (MSMQ)

Расшифровывается это как Message Queuing (MSMQ) или Сервер очередей сообщений Microsoft. Очередь сообщений создана для взаимодействия приложений в распределенной среде (на разных компьютерах). Мы уже рассматривали подобные механизмы, например, socket или DCOM. Особенность MSMQ в том, что компьютеры не обязательно должны быть одновременно в сети. То есть можно отправить сообщение, можно получить, а за всем этим следит сервер MSMQ.

Есть несколько деталей, которые отличают очереди сообщений от других механизмов обмена данными в распределенной системе.

Доставка между клиентами одновременно не подключенными

Очередь сообщений поддерживается операционной системой

Очередь сообщений поддерживает транзакции

MSMQ 1.0 используется в Windows NT 4.0, Windows 95, and Windows 98.

MSMQ 2.0 используется в Microsoft® Windows® 2000.

Этот протокол действительно оправдывает свое название - он обеспечивает посылку сообщений между приложениями с помощью очереди сообщений. Основное его отличие от стандартной очереди сообщений Windows в том, что он может работать с удаленными процессами и даже с процессами, которые на данный момент недоступны (например, не запущены). Доставка сообщения по адресу гарантируется. Оно ставится в специальную очередь сообщений и находится там до тех пор, пока не появляется возможность его доставить.

Удаленный вызов процедур (Remote Procedure Call, RPC)

Строго говоря, это не совсем технология IPC, а скорее способ значительно расширить возможности других механизмов IPC. С помощью этой технологии общение через сеть становится совешенно прозрачным как для сервера, так и для клиента. Им обоим начинает казаться, что их "собеседник" расположен локально по отношению к ним.

Удалённый вызов процедур (или Вызов удалённых процедур) (от англ. Remote Procedure Call (RPC)) -- класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях: одни реализуют архитектуру SOA, другие CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некоторые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).

Принцип

Идея вызова удалённых процедур (Remote Procedure Call -- RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова удалённых процедур являются:

· Асимметричность, то есть одна из взаимодействующих сторон является инициатором;

· Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.

Реализация удалённых вызовов существенно сложнее реализации вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:

· Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выполнения через сеть выполняется их сериализация.

· В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика.

· Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса -- по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удалённо вызванные процедуры станут «осиротевшими», а при аварийном завершении удалённых процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удалённых процедур.

· Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандарта, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.

Библиотекой называется совокупность функций, объединенных в один файл и хранящихся в скомпилированном виде.

Код библиотеки статической компоновки связывается с кодом программы в процессе сборки исполняемого EXE файла. Эту работу выполняет компоновщик, входящий в состав интегрированной среды разработки.

Библиотеки в Windows могут быть статической (.LIB) и динамической (.DLL) компоновки.

Основная особенность библиотек динамической компоновки состоит в том, что она связывается с программой не на этапе сборки, а во время выполнения программы.

В результате получаем преимущества:

1. Один и тот же код может использоваться несколькими программами (достигается экономия памяти).
2. Упрощается процесс внесения изменений в программы (достаточно заменить библиотеку).

Недостатки:

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

1.2 Простая dll

Создание dll в Visual C++

Опишем по шагам процесс создания простой динамической библиотеки в Microsoft Visual C++ 2008 Express ed.

Шаг 1 . Создадим новый проект

Шаг 2 . Выберем категорию проекта, название и расположение на диске

Шаг 3 . Выберем настройки проекта

Шаг 4 . Добавим в созданный проект новый.cpp-файл

Шаг 5 . Укажем тип файла: .cpp

Шаг 6 . Добавим текст библиотеки

Библиотека будет состоять всего из 2-х функций:

1. DllMain - главная функция библиотеки, аналог main в консольных программах.
2. fnsimple_dll - пробная функция, не принимающая параметров и возвращающая целое число (константу 100).

Шаг 7 . Добавим в библиотеку def -файл для экспортирования имени функции fnsimple_dll

Шаг 8 . Укажем имя: simple_dll.def (имя совпадает с именем библиотеки)

Шаг 9 . В .def -файл поместим несколько строк, содержащих имя динамической библиотеки (раздел LIBRARY ) и имена экспортируемых функций (раздел EXPORTS )

Шаг 10 . Выберем настройки свойств проекта (Properties )

Шаг 11 . Укажем имя только что созданного def-файла в строке с параметром Module Definition File и сохраним настройки

Последний шаг - это построение библиотеки (Build ).

Если на этапе построения возникают ошибки, то нужно внимательно изучить текст cpp -файла и устранить опечатки.

Результатом работы компилятора и компоновщика будет появление файла simple_dll.dll в подкаталоге Debug каталога проекта. Этот файл можно копировать в любое место файловой системы.

2 Работа с dll

2.1 Работа с dll из консольного приложения

Консольное приложение

Необходимо создать новое консольное приложение и назвать его test_dll . В проект добавить cpp -файл и поместить туда следующее содержимое (путь к файлу библиотеки нужно указать свой)

Приведённый текст программы иллюстрирует порядок работы с функциями из библиотеки:

Шаг 1. Подключаем заголовочный файл windows.h и файлы, необходимые для компиляции содержимого библиотеки. В нашем случае - это консольный ввод/вывод.

Шаг 2. Объявляем указатели на функции, содержащиеся в библиотеке. В нашем примере это функция, которая не принимает параметров, но возвращает целое число.

Int (* fnsimple_dll)();

Шаг 3. Объявляем специальную переменную для работы с библиотекой

HMODULE lib;

Шаг 4. Загружаем библиотеку при помощи функции LoadLibraryA с указанием имени файла. Имя файла может быть как относительным, так и абсолютным. После вызова функции необходимо проверить содержимое переменной lib .

Шаг 5. Если загрузка библиотеки прошла успешно, то мы пытаемся связать ранее объявленный указатель на функцию с функцией из библиотеки с помощью GetProcAddress . В качестве параметров указывается lib и название функции. Результат необходимо явно преобразовать к типу указателя.

Шаг 6. Если предыдущий шаг завершился успешно, то можно вызывать функцию из dll. Если нет, то необходимо проверить настройки экспорта в simple_dll и перекомпилировать библиотеку.

Шаг 7. Освободим ресурсы, занимаемые библиотекой, через вызов функции FreeLibrary

После запуска программы можно видеть результат, возвращаемый fnsimple_dll

2.2 Работа с dll из MS Excel

MS Excel

Для того, чтобы вызвать функцию, расположенную в динамической библиотеке, из электронной таблицы MS Excel нужно сделать следующее:

1. Вставить в рабочую книгу Модуль
2. Поместить в модуль объявление функций из динамической библиотеки

Шаг 1. Запустить MS Excel и вызвать настройки параметров

Шаг 2. Установить значение параметра Показывать вкладку Разработчик на ленте

Шаг 3. Перейти в редактор Visual Basic и вставить в рабочую книгу новый модуль

Шаг 4. Поместить в модуль объявление функции из dll

Шаг 5. Перейти на рабочий лист и вызвать Мастер функций . Выбрать категорию Определённые пользователем

Шаг 6. Поместить вызов функции в ячейку

Вопросы для самоконтроля

1. Что такое библиотека функций?
2. В чём особенности библиотек статической компоновки?
3. Перечислите достоинства dll.
4. В чём состоят недостатки dll?
5. Что является результатом построения проекта?

Список литературы

1. Богатырёв А. Язык С в системе Unix.. 111.
2. Подбельский В.В., Фомин С.С. Программирование на языке С.. 111.
3. Голуб А. Правила программирования на С и С++.. 111.
4. Хэзфилд Р., Кирби Л. Искусство программирования на С.. 111.
5. Дейтел Х., Дейтел П. Как программировать на С.. 111.
6. Керниган Б.,Ритчи Д. Язык С.. 111.