ПРОГРАММИРОВАНИЕ НА VISUAL C++

Выпуск No. 36 от 11 марта 2001 г.

Здравствуйте!

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

/ / / / СТАТЬЯ / / / / / / / / / / / / / / / / / / / / / /

IPC: основы межпроцессного взаимодействия
Обзор технологий

Введение

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

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

Рассмотрим подробнее несколько ключевых примеров, демонстрирующих важность IPC. Вам, возможно это покажется неправдоподобным, но зачатки IPC существовали еще в MS-DOS - и это несмотря на то, что MS-DOS при всем желании трудно назвать многозадачной средой. В самом деле, когда вы в командной строке вводили подобную инструкцию :

C:\>DIR|MORE

происходило следующее: выполнялась команда DIR и ее вывод записывался во временный текстовый файл. После этого содержимое файла подавалось на вход команды MORE. В результате вы получали листинг каталогов, который в случае большого количества каталогов не уезжал мгновенно за экран, а мог скроллироваться с помощью клавиши Enter. Конечно же это очень примитивный IPC, но его наличие показывает, что уже тогда такой механизм был востребован и в какой-то мере реализован.

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

ПРИМЕЧАНИЕ Вообще, для сетевых форм IPC (но не обязательно только для них) очень часто используется концепция "клиент-сервер". Как вы понимаете, "клиент" - это приложение, которому требуются данные, "сервер" - приложение, предоставляющее данные.

А если брать только взаимодействие программ, выполняющихся на одном компьютере, самым банальным примером будет следующий: текст из вашего текcтового редактора передается в электронную таблицу или программу для верстки. Да-да, наш старый знакомый буфер обмена - это тоже один из механизмов IPC!
И еще можно было бы привести очень много примеров.

Средств, обеспечивающих взаимодействие между процессами, создано достаточно много. Огромное их количество реализовано в Windows 9x, еще больше - в Windows NT/2000. Теперь нужно приличное количество времени, чтобы хотя бы познакомиться со всеми! Замечу, что нет, и наверное в принципе не может быть универсального способа обмена данными, который годился бы на все случаи жизни - все равно в некоторых случаях использование другого способа будет предпочтительнее. Но я надеюсь, что после прочтения этой статьи вы сможете достаточно уверенно ориентироваться в мире IPC и обоснованно выбирать тот или иной метод.

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

Вообще, правильнее было бы называть эти механизмы "Interthread Communication" - межпотоковое взаимодействие. Если вы помните, выполняются именно потоки, они же и обмениваются данными. Однако, смысл для отдельных механизмов взаимодействия появляется только в том случае, если эти потоки принадлежат разным процессам. Ведь потоки, выполняющиеся в рамках одного процесса, вовсе не нуждаются в дополнительных средствах для общения между собой. Так как они разделяют одно адресное пространство, обмен данными могут обеспечить обычные переменные. Таким образом, IPC становится необходим в том случае, если поток одного процесса должен передать данные потоку другого процесса.

Теперь давайте рассмотрим основные виды IPC и случаи, в которых они используются.

Буфер обмена (clipboard)

Сообщение WM_COPYDATA

Разделяемая память (shared memory)

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

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

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

OLE/ActiveX

Каналы (pipes)

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

Сокеты (sockets)

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

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

Microsoft Message Queue (MSMQ)

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

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

Резюме

/ / / / ВОПРОС-ОТВЕТ / / / / / / / / / / / / / / / /

Q| Можно ли из моей программы управлять окном которое создано другим приложением (закрывать, сворачивать, нажимать в нем кнопки и т.д.), если да то как? - Alhim

|A Выполнение этой задачи распадается на два этапа.

Сначала нужно каким-то образом определить хэндл окна, которым мы собираемся манипулировать. Основным инструментом здесь являются функции FindWindow(Ex), которые ищут окно по заданному классу и/или заголовку. В определении и того, и другого сильно помогает программа Spy++. Рассмотрим пример поиска HWND стандартной кнопки "Пуск". Сначала используем Spy++, чтобы определить классы панели задач и самой кнопки; оказывается, их имена "Shell_TrayWnd" и "Button" соответственно. Затем используем FindWindow(Ex).

 HWND hWnd;
 hWnd = FindWindow("Shell_TrayWnd", NULL);
 hWnd = FindWindowEx(hWnd, NULL, "Button", NULL);

 if (IsWindow(hWnd))
 {
  // Кнопка найдена, работаем с ней
 }

Ещё один набор функций, которые могут помочь в поиске хэндла чужого окна - это EnumChildWindows, EnumThreadWindows и EnumWindows, перечисляющие все окна, принадлежащие заданному окну, все окна заданного потока и все окна в системе соответственно. За описанием этих функций следует обратиться к документации. Кроме перечисленного можно упомянуть случай, когда приложение специально проектируется для взаимодействие с другим посредством обмена сообщениями. Например, одно приложение запускает другое, а затем обменивается с ним данными посредством WM_COPYDATA. В этом случае вполне уместно передать хэндл окна (это 4-хбайтовое целое) как параметр командной строки. После того, как хэндл окна определён, можно переходить ко второму этапу - управлению окном. Многие функции позволяют работать с окном, вне зависимости от того, какому процессу оно принадлежит. Характерные примеры таких функций - ShowWindow и SetForegroundWindow. Для примера рассмотрим, как спрятать кнопку "Пуск", получать хэндл которой мы уже научились.

 HWND hWnd;
 hWnd = FindWindow("Shell_TrayWnd", NULL);
 hWnd = FindWindowEx(hWnd, NULL, "Button", NULL);

 if (IsWindow(hWnd))
 {
  ShowWindow(hWnd, SW_HIDE);
  Sleep(5000);
  ShowWindow(hWnd, SW_SHOW); // Показываем обратно
 }

Кроме использования подобных функций, можно посылать окну сообщения. Например, послав кнопке BM_CLICK (с помощью PostMessage), мы как бы нажимаем на неё.

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

Существует несколько способов внедрить DLL в чужой процесс. Я покажу один из них; он достаточно прост и работает на всех Win32-платформах (Windows 9x, Windows NT), но в некоторых случаях недостаточно точен. Этот способ подразумевает установку хука на поток, создавший интересующее нас окно. При этом DLL, содержащая функцию хука, загружается системой в адресное пространство чужого процесса. Это как раз то, что нам нужно. А функцию хука вполне можно оставить пустой.

Рассмотрим пример DLL, которая уничтожает окно чужого процесса. (Такие вещи нужно делать, только полностью отдавая себе отчёт о возможных последствиях. Процесс, оставленный без окна, имеет хорошие шансы "рухнуть").

// _KillDll.cpp : Defines the entry point for the DLL application.
//

#include <windows.h>

// Создаём переменную в разделяемом сегменте,
// чтобы передать HWND из программы в DLL в чужом процессе.
#pragma comment(linker, "/SECTION:SHARED,RWS")
#pragma data_seg("SHARED")
__declspec(allocate("SHARED")) HWND hWndToKill = NULL;
#pragma data_seg()

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved )
{
 if (ul_reason_for_call == DLL_PROCESS_ATTACH &&
  IsWindow(hWndToKill) &&
  GetWindowThreadProcessId(hWndToKill, NULL) == GetCurrentThreadId())
 {
  // Если окно существует и принадлежит текущему потоку, убиваем его.
  HANDLE hEvent = OpenEvent(NULL, FALSE,
"{1F6C5480-155E-11d5-93A8-444553540000}");
  DestroyWindow(hWndToKill);
  SetEvent(hEvent);
  CloseHandle(hEvent);
 }

  return TRUE;
}

// Пустая функция хука.
LRESULT CALLBACK GetMsgProc(int code, WPARAM wParam, LPARAM lParam)
{
 return 1;
}

extern "C" __declspec(dllexport) void KillWndNow(HWND hWnd)
{
 if (!IsWindow(hWnd))
  return;

 hWndToKill = hWnd;

 HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE,
"{1F6C5480-155E-11d5-93A8-444553540000}");

 DWORD dwThread = GetWindowThreadProcessId(hWnd, NULL);
 HHOOK hHook = SetWindowsHookEx(
  WH_GETMESSAGE,
  GetMsgProc,
  GetModuleHandle("_KillDll.dll"),
  dwThread);
 PostThreadMessage(dwThread, WM_NULL, 0, 0);

 WaitForSingleObject(hEvent, INFINITE);
 CloseHandle(hEvent);

 UnhookWindowsHookEx(hHook);
}

Чтобы использовать эту DLL, просто подключите её к программе (проще всего сделать это неявным методом), а затем выполните код:

extern "C" void KillWndNow(HWND hWnd);
 ...
HWND hWnd;
// Ищем окно
KillWndNow(hWnd);

Хотя код DLL сам по себе и небольшой, в нём есть несколько тонкостей, на которые я хотел бы обратить ваше внимание. Во-первых, я поместил переменную hWndToKill в разделяемый сегмент. Поскольку функция DestroyWindow вызывается в потоке чужого процесса, необходимо предусмотреть некоторый способ передачи хэндла окна через границы процессов. Разделяемая переменная - наиболее простое средство достичь цели. Во-вторых, DLL, содержащая функцию хука, не будет спроектирована на адресное пространство чужого процесса, пока функция хука реально не понадобится. В нашем случае хук имеет тип WH_GETMESSAGE, а значит DLL не загрузится, пока поток не получит какое-либо сообщение. Поэтому я посылаю ему сообщение WM_NULL (с кодом 0), чтобы вынудить ОС загрузить DLL. В-третьих, обратите внимание на применение события для синхронизации потоков в нашем и целевом процессах. Разумеется, для этой цели можно использовать и любой другой механизм синхронизации потоков. - Александр Шаргин (rudankort@mail.ru)

/ / / В ПОИСКАХ ИСТИНЫ / / / / / / / / / / / / /

Q| Хотелось бы побольше узнать о предварительном просмотре. В русской программе он смотрится инородным телом на своем иностранном языке. Можно ли его как-то настраивать под себя?
В этой же связи: не могу решить проблему.
В программе 3 меню и, соответственно, 3 панели инструментов, которые создал в Create. Переключая меню, вызываю ShowControlBar - прячу ненужные панели и показываю необходимую. Но после вызова PRINT PREVIEW, в окне появляются сразу все 3 панели инструментов.
Попутно: что означает AFX_IDS_PREVIEW_CLOSE в String Table? - Serg Petukhov

   Ответить на вопрос

/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

Успехов!

Алекс Jenter   jenter@mail.ru
Красноярск, 2001.