();
RemoveHook := True;
end
else
RemoveHook := False;
end;
Тут все просто и не требует подробного пояснения. Теперь же рассмотрим так часто используемые функцию и процедуру, работающие с проекцией файла в память. Функция GetFileMapping, приведенная в листинге 10.23, открывает проекцию файла в память и связывает указатель hookinf о с областью памяти, отведенной для проекции файла.
Листинг 10.23.
Открытие проекции файла
function GetFileMapping(): Boolean;
begin
//Пытаемся открыть проекцию файла
hFile := OpenFileMapping (FILE_MAP_WRITE, False, PAnsiChar(strFileMapName));
//Получаем адрес разделяемой памяти
hook_info := MapViewOfFile(hFile, FILE_MAP_WRITE, 0, 0, SizeOf (THookInfo));
GetFileMapping := hook_info <> nil;
end;
Процедура ReleaseFileMapping, симметричная по своему назначению функции GetFileMapping, реализована так, как показано в листинге 10.24.
Листинг 10.24.
Освобождение проекции файла
procedure ReleaseFileMapping ();
begin
UnmapViewOfFile(hook_info);
hook_info := nil;
CloseHandle (hFile);
hFile := 0;
end;
Функция GetFileMapping и процедура ReleaseFileMapping используют дополнительно глобальную переменную hFile (тип THandle), объявленную в модуле HookData.
Наконец пришла очередь функции-ловушки. Ее реализация приведена в листинге 10.25.
Листинг 10.25.
Функция-ловушка
function WndProcHook(code: Integer; wparam: WPARAM;
lparam: LPARAM): LRESULT stdcall;
var
hook_data: ^TCWPStruct;
begin
//Получим доступ к проекции файла
if not GetFileMapping() then
begin
//Не удалось получить доступ к проекции файла. Ценой потери
//сообщений не дадим возникнуть ошибкам доступа к памяти
WndProcHook := 0;
Exit;
end;
if code < 0 then
begin
WndProcHook := CallNextHookEx(hook_info^.hook_handle, code,
wParam, lParam);
//Освободим проекцию файла
ReleaseFileMapping();
Exit;
end;
//Можно обрабатывать сообщение
hook_data := Pointer(lParam);
//Обрабатываем только сообщения нужного окна
if hook_data^.hwnd = hook_info^.wnd then
begin
//Заполняем поля структуры в общей области памяти и посылаем
//сообщение окну-шпиону
hook_info^.mess := hook_data^.message;
hook_info^.wParam := hook_data^.wParam;
hook_info^.lParam := hook_data^.lParam;
PostMessage(hook_info^.spy_wnd, WM_SPY_NOTIFY, 0, 0);
end;
//Передаем сообщение для дальнейшей обработки
WndProcHook := CallNextHookEx(hook_info^.hook_handle, code,
wParam, lParam);
//Освободим проекцию файла
ReleaseFileMapping();
end;
Код функции WndProc достаточно прост, поэтому не будем подробно его описывать. Поясним лишь, для чего все-таки GetFileMapping и ReleaseFileMapping вызываются при обработке каждого перехваченного сообщения.
Дело в том, что загрузка DLL в адресное пространство другого процесса отличается от штатной загрузки библиотеки, например, при помощи функции LoadLibrary: не вызывается код инициализации. Следовательно, мы не можем, например, обнулить указатель hookinf о или установить еще какой-либо признак того, была ли открыта проекция файла. Велика вероятность того, что без отсутствия ручной инициализации указатель hookinf о не будет равен нулю. Как тогда определить, связан ли этот указатель с областью памяти, куда спроецирован файл?
Можно было бы, конечно, завести 64- битную или более переменную, которой присваивалось бы «магическое» число при первой инициализации указателя hookinf о. Но в таком случае работоспособность нашей программы носила бы вероятностный характер.
Речь не идет о том, что в приведенном примере ловушка реализована самым оптимальным образом, просто альтернатива cGetFileMapping HReleaseFileMapping при написании программы показалась наиболее простой и легко поддающейся объяснению.
Глава 11 Сетевое взаимодействие
• Краткое описание сетевых компонентов
• Простой обмен данными
• Слежение за компьютером по сети
• Многопользовательский разговорник
Организация надежного сетевого взаимодействия между приложениями или компонентами одного приложения зачастую является задачей довольно сложной даже для программиста со значительным опытом работы. Это правда, если пытаться самостоятельно использовать API сетевого взаимодействия, предоставляемый операционной системой (в нашем случае – Windows). Однако с использованием компонентов Delphi, в которых уже реализованы рутинные операции по созданию соединений, пересылке данных, контролю ошибок и т. д., программирование сетевых приложений становится не только простым, но и увлекательным занятием. В данной главе мы рассмотрим несколько примеров создания несложных сетевых приложений, построенных с использованием архитектуры «клиент – сервер».
11.1. Краткое описание сетевых компонентов
В Delphi 7 количество компонентов для программирования самых различных сетевых приложений просто радует глаз (см. вкладки IndyQients и IndyServers). Мы рассмотрим построение приложения на базе только IdTCPServer и IdTCPCLient (написание клиент-серверных приложений с использованием всех сетевых компонентов могло бы занять всю книгу).
Итак, сначала о компоненте сервера IdTCPServer. Для использования возможностей сервера этот компонент нужно поместить на форму (компонент неотображаемый). При настройке компонента полезными являются следующие его свойства:
• Active – активизирует или деактивизирует сервер (по умолчанию False);
• Bindings – настраивает серверные сокеты (присоединяет их к определенному порту компьютера, позволяет задавать диапазон IP- адресов и портов клиентов) при помощи диалогового окна Binding Editor;
• ListenQueue – численное значение, ограничивающее максимальное количество запросов на установление соединения от клиентов в очереди;
• MaxConnections – позволяет ограничить максимальное количество клиентов, присоединенных к серверу;
• MaxConnectionReply – позволяет настроить сообщение, посылаемое сервером новым клиентам, когда их количество достигает MaxConnections.
Рассмотрим несколько подробнее настройку серверных гнезд с использованием свойства Bindings. Так, на рис. 11.1 показано, как при помощи диалогового окна Binding Editor настроить сервер на обслуживание клиентов с любыми IP- адресами, при этом серверный сокет присоединяется к порту 12340.
Рис. 11.1. Использование окна Binding Editor
Для более детальной настройки каждого серверного сокета можно использовать окна Object TreeView и Object Inspector так, как показано на рис. 11.2.
На этом настройку сервера можно и завершить (хотя здесь используются далеко не все возможности компонента IdTCPServer). Основная же работа сервера при обработке запросов клиентов может реализоваться в обработчике события OnExecute. В этот обработчик передается ссылка на o6beKTTIdPeerThread – поток, ассоциированный с клиентом, присоединенным к серверу. Посредством этого объекта (а точнее, его свойства Connection) можно получать и отправлять данные, а также получать и устанавливать множество полезных параметров соединения. Первый пример использования объекта TIdPeerThread при обработке запроса клиента приведен в листинге 11.1.
Теперь рассмотрим, как сконфигурировать клиент (IdTCPQient), чтобы он был способен взаимодействовать с нашим сервером. Чтобы использовать компонент ТСР-клиента, достаточно поместить его на форму (компонент также неотображаемый).
После этого как минимум нужно настроить следующие его свойства (остальные упоминаются по мере необходимости в приведенных далее примерах):
• Host – имя или IP-адрес компьютера, на котором запущен сервер;
• Port – номер порта, к которому присоединен серверный сокет.
Вообще, даже эти свойства на этапе разработки формы настраивать не обязательно. Приложение получается гораздо более гибким, если давать, например, пользователю возможность выбрать (или ввести) имя или адрес сервера.11.2. Простой обмен данными
В начале работы с описанными в предыдущем разделе компонентами IdTCPServer и IdTCPChent рассмотрим создание несложного клиент-серверного приложения, клиентская и серверная части которого выполняют следующие функции.
• Клиентское приложение соединяется с сервером и отправляет ему введенную пользователем строку, ждет ответа, выводит полученный от сервера текст,
