4.3.3. Технологии обмена данными между процессами

В Windows каждому процессу выделяется собственное виртуальное адресное пространство. Для 32-разрядных процессов его размер составляет 4 гигабайт, для 64-разрядных – 16 экзабайт.

Адресное пространство одного процесса наглухо закрыто для другого, поэтому даже самые назойливые процессы не могут напрямую вмешиваться в деятельность своих коллег.

Безусловно, один из процессов вправе в своем виртуальном адресном пространстве по какому-то адресу 0x12345678 разместить данные, которыми он не прочь поделиться с другими приложениями. Но беда в том, что для других процессов по этому адресу может находиться все что угодно, но только не требуемые данные, ведь речь идет об адресе в виртуальном адресном пространстве отдельного процесса, и он не имеет ничего общего с реальным физическим адресом. Рассмотрим, каким образом в таких непростых условиях решить задачу обмена данными между несколькими процессами.

4.3.3.1. Буфер обмена

Буфер обмена предназначен для передачи различного типа данных между приложениями или внутри одного приложения. Функционально в среде Windows буфер обмена представляет собой некоторый перечень методов Win32 API, осуществляющих операции с областью памяти, а именно загрузку в память и выгрузку из памяти данных различного типа. Для удобства работы с буфером обмена в Delphi внедрен специальный класс TClipboard, описанный в модуле Clipbrd. Присоединив этот модуль к проекту в строке uses, вы получите доступ к буферу обмена при помощи функции Clipboard.

function Clipboard: TClipboard;

Конструктор, создающий экземпляр класса TClipboard, не требуется, так как эта операция производится в рамках данного метода.

Буфер обмена служит универсальным хранилищем данных и позволяет размещать в себе обычную текстовую информацию, растровые и векторные рисунки, объекты OLE и т. п. Однако для различных типов данных, направляемых в буфер, требуются различные способы их хранения, которые определяются так называемым форматом буфера обмена. Для ключевых, наиболее часто используемых типов объектов в Microsoft Windows описаны специальные форматы, называемые зарегистрированными форматами буфера обмена.

Однако если приложение предполагает размещать в буфере какую-то экзотическую информацию, то программист имеет право описать и зарегистрировать в системе собственный пользовательский формат. Для таких целей в состав Win API включена функция RegisterClipboardFormat(). Формат, регистрируемый этим методом, определяет способ распределения области памяти, в которой будет храниться объект.

4.3.3.2. Динамический обмен данными

В списке изучаемых в данной главе способов межпрограммного взаимодействия технология DDE (Dynamic Data Exchange – динамический обмен данными) является весьма старой; по древности ее опережает лишь буфер обмена.

Технология DDE была разработана в недрах Microsoft еще для первых версий Windows и с тех времен не претерпела серьезных изменений. Однако пожилой возраст технологии нельзя считать серьезным поводом для досрочного списания DDE со счетов. Одно из ключевых преимуществ DDE над современными методами совместной работы приложений заключается в малой требовательности к ресурсам компьютера (разве можно сравнить вычислительные возможности современного Pentium IV с компьютером на базе 286 микропроцессора, для которого создавалась DDE). К списку достоинств DDE стоит отнести и относительную простоту программной реализации этого процесса.

Основная задача DDE – обеспечить обмен данными между двумя приложениями: клиентом и сервером. В простейшем случае процесс передачи односторонний – клиент DDE инициирует процесс, запрашивая необходимые ему данные. Если сервер DDE в состоянии ответить на запрос, он отправляет требуемые данные клиенту DDE. Процесс передачи данных называют сеансом обмена DDE.

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

Открытие сеанса DDE инициируется на клиентской стороне. Эту операцию с некоторой степенью приближения можно сравнить с процессом заказа авиабилета по телефону. Вы набираете телефонный номер службы заказов, вступаете в разговор с оператором на тему «что летит в Магадан» и заказываете билет на устраивающий вас рейс. Если вы попытаетесь общаться с сервером на незнакомую ему тему или инициируете сеанс с искаженным именем сервиса, то, увы, сеанс DDE не состоится.

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

1. Определение имени сервиса (Service Name) обеспечит доступ к интересующему нас приложению-серверу DDE (аналог – набор телефонного номера службы заказа).

2. Указание, на какую тему (topic) вы хотите поговорить с сервером («что летит в Магадан»).

3. Выбор в теме соответствующего предмета обсуждения (item) – заказ билета.

Для разработки приложений, способных поддерживать сеанс DDE, в Delphi созданы четыре специальных класса: TDDEClientConv, TDDEClientItem, TDDEServerConv и TDDEServerItem. По их названиям можно догадаться, что два первых элемента управления специализируются на создании клиентских приложений, а два последних нацелены на реализацию приложения-сервера DDE.

Непосредственно за организацию контакта отвечают классы TDDEClientConv и TDDEServerConv.

На основе перечисленных классов реализованы невизуальные компоненты; они размещены на странице System палитры компонентов Delphi.