3. Библиотеки динамической компоновки

• 3.1. Статическая и динамическая компоновка
• 3.2. DLL-библиотеки в операционной системе Windows
• 3.3. Структура DLL-библиотеки
• 3.4. Приложение DLLCALL
• 3.5. Приложение DISCARD
• 3.6. Фильтры
• 3.7. Приложение WINHOOK

В этой главе мы расскажем вам о важнейшем механизме, лежащем в основе операционной системы Windows - механизме библиотек динамической компоновки DLL. Если вы уже заметили, в Windows имеется много важнейших механизмов и систем, например, только что рассмотренная система управления памятью, интерфейс графических устройств GDI, система динамического обмена данными DDE, система управления шрифтами, интерфейсы для мультимедиа, система динамической вставки и привязки объектов OLE, и так далее, и так почти до бесконечности.

Однако будем терпеливыми, и постараемся сосредоточиться, так как вся операционная система Windows и все ее драйверы (кроме виртуальных), а также другие расширения в некотором смысле есть ни что иное, как набор библиотек динамической компоновки. Редкое крупное приложение Windows обходится без собственных библиотек динамической компоновки, и ни одно приложение не может обойтись без вызова функций, расположенных в таких библиотеках. В частности, все функции программного интерфейса Windows находятся именно в библиотеках динамической компоновки DLL (Dynamic-Link Libraries ).

Что же это за библиотеки и почему они имеют такое большое значение?

3.1. Статическая и динамическая компоновка

Вспомним старые добрые времена, когда операционная система MS-DOS и компьютеры с памятью 1 Мбайт удовлетворяли запросы подавляющего большинства пользователей. Как создавался загрузочный файл программы для MS-DOS? Вы готовили исходный текст приложения на своем любимом языке программирования (Си, Паскаль, Модула-2 и т. д.), затем транслировали его для получения объектного модуля. После этого в дело включался редактор связей, который компоновал объектные модули, полученные в результате трансляции исходных текстов и модули из библиотек объектных модулей, в один exe-файл. В процессе запуска файл программы загружался полностью в оперативную память и ему передавалось управление.

Таким образом, редактор связей записывал в файл программы все модули, необходимые для работы. Для обращения к внешним по отношению к программам модулям операционной системы MS-DOS и модулям BIOS использовался механизм программных прерываний. В любой момент времени в оперативной и постоянной памяти компьютера находился весь код, необходимый для работы как запущенной программы, так и самой операционной системы MS-DOS.

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

В среде мультизадачной операционной системы, такой как Windows, OS/2 или UNIX, статическая компоновка неэффективна, так как приводит к неэкономному использованию очень дефицитного ресурса - оперативной памяти. Представьте себе, что в системе одновременно работают 5 приложений, и все они вызывают такие функции, как sprintf, memcpy, strcmp и т. д. Если приложения были собраны с использованием статической компоновки, в памяти будут находится одновременно 5 копий функции sprintf, 5 копий функции memcpy, и т. д (рис. 3.1). А ведь программы могут использовать и более сложные функции, например, предназначенные для работы с диалоговыми панелями или масштабируемыми шрифтами!

Рис. 3.1. Вызов функций при использовании статической компоновки

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

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

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

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

Рис. 3.2. Вызов функции при использовании динамической компоновки

В операционной системе Windows версии 3.1 файлы библиотек динамической компоновки (DLL-библиотеки) имеют расширение имени dll, хотя можно использовать любое другое, например, exe. В первых версиях Windows DLL-библиотеки располагались в файлах с расширением имени exe. Возможно поэтому файлы krnl286.exe, krnl386.exe, gdi.exe и user.exe имеют расширение имени exe, а не dll, не смотря на то, что перечисленные выше файлы, составляющие ядро операционной системы Windows, есть ни что иное, как DLL-библиотеки.

Механизм динамической компоновки используется не только в системе Windows. Более того, он был изобретен задолго до появления Windows. Например, в мультизадачных многопользовательских операционных системах VS1, VS2, MVS, VM, созданных для компьютеров IBM-370 и аналогичных (вспомните добрым словом ушедшую в прошлое серию ЕС ЭВМ и операционные системы SVS, TKS, СВМ, МВС), код функций, нужных параллельно работающим программам, располагается в отдельных библиотеках и может загружаться при необходимости в специально выделенную общую область памяти. Операционная система OS/2 также работает с DLL-библиотеками.

3.2. DLL-библиотеки в операционной системе Windows

Формат DLL-библиотеки почти идентичен формату загрузочного модуля приложения Windows, однако вы не можете "запустить" DLL-библиотеку на выполнение, как обычное приложение. И это понятно, так как назначение DLL-библиотек другое - они служат хранилищем функций, вызываемых приложениями во время работы. Функции, расположенные в DLL-библиотеках, могут вызывать функции, которые находятся в других библиотеках (рис. 3.3).

Рис. 3.3. Вызов функций из DLL-библиотек

Для того чтобы вам были понятны отличия между приложением и DLL-библиотекой, уточним такие понятия, как задача (task ), копия приложения (instance ) и модуль (module ).

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

Рис. 3.4. Копии приложения и модуль приложения

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

Копия приложения (instance) является контекстом, в котором выполняется модуль приложения. Идентификатор копии приложения, который вы получаете через параметр hInstance функции WinMain, является идентификатором сегмента данных DGROUP, используемого при выполнении программного модуля.

Модуль приложения (module) состоит из исполнимого кода и ресурсов. Внутри Windows есть база данных модулей, в которой хранится такая информация, как ссылки на экспортируемые функции, расположение сегментов кода и сегментов, содержащих ресурсы. Так как модуль приложения не изменяется (сегменты кода и ресурсов не изменяются), все запущенные копии одного приложения могут им пользоваться.

DLL-библиотека также является модулем. Она находится в памяти в единственном экземпляре, содержит сегменты кода и ресурсы, а так же один сегмент данных (рис. 3.5). Можно сказать, что для DLL-библиотеки создается одна копия (instance), состоящая только из сегмента данных, и один модуль, состоящий из кода и ресурсов.

Рис. 3.5. Структура DLL-библиотеки в памяти

DLL-библиотека, в отличие от приложения, не имеет стека и очереди сообщения.

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

Тем не менее, функции, расположенные в DLL-библиотеке, пользуются сегментом данных, принадлежащей этой библиотеке, а не копии приложения. При этом возникают трудности, связанные с тем, что сегментный регистр SS, с помощью которого адресуется стек, указывает на стек копии приложения, а регистр DS - на сегмент данных DLL-библиотеки. В обычных приложениях Windows регистры SS и DS адресуют один и тот же автоматический сегмент данных. Позже мы займемся этим вопросом вплотную.

Для чего используются DLL-библиотеки ?

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

С помощью DLL-библиотек можно организовать коллективное использование ресурсов или данных, расположенных в сегменте данных библиотеки. Более того, вы можете создать DLL-библиотеки, состоящие только из одних ресурсов, например, из пиктограмм или изображений bitmap. В состав Windows входит DLL-библиотека moricons.dll, состоящая из одних пиктограмм. Файлы с расширением fon представляют собой ни что иное, как DLL-библиотеки, содержащие шрифты в виде ресурса.

Функции, входящие в состав DLL-библиотеки, могут заказывать блоки памяти с атрибутом GMEM_SHARE. Такой блок памяти не принадлежит ни одному приложению и поэтому не освобождается автоматически при завершении работы приложения. Так как в Windows версии 3.1 все приложения используют общую глобальную память, блоки памяти с атрибутом GMEM_SHARE можно использовать для обмена данными между приложениями. Управлять таким обменом могут, например, функции, расположенные в соответствующей DLL-библиотеке. Однако в следующих версиях Windows каждое приложение будет работать в собственном адресном пространстве, поэтому для организации обмена данных между приложениями следует использовать специальный механизм динамического обмена данными DDE, который мы рассмотрим позже в отдельной главе.

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

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

Например, приложение может организовать "перехват" системных сообщений или функций, при этом соответствующие модули "перехватчика" необходимо располагать в фиксированном сегменте кода DLL-библиотеки. Для удаляемых (discardable) блоков памяти можно, вызвав функцию GlobalNotify, определить функцию, которой будет передаваться управление при попытке удалить блок из памяти. Такая функция должна находиться в фиксированном сегменте кода в DLL-библиотеке. Если ваше приложение обрабатывает аппаратные прерывания или само вызывает программные прерывания, ему также не обойтись без DLL-библиотек (единственный способ обработки прерываний в реальном времени - создание виртуального драйвера). Наконец, все обычные драйвера устройств в операционной системе Windows реализованы с помощью DLL-библиотек.

Даже если вы не собираетесь обрабатывать или вызывать прерывания и не разрабатываете собственный драйвер, отдельные подсистемы большого приложения имеет смысл оформлять в виде DLL-библиотек из соображений модульности и доступности библиотек для других приложений. Например, в приложении SMARTPAD мы создали орган управления Toolbar с использованием разработанного нами класса С++ Toolbar. Однако если бы мы сосредоточили все функции этого класса в DLL-библиотеке, нашим органом управления могли бы воспользоваться и другие созданные нами приложения.

Разумеется, у динамической компоновки есть и свои недостатки.

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

Во-вторых, в дополнение к exe-файлу вместе с приложением необходимо устанавливать один или несколько dll-файлов, что в некоторой степени усложняет процесс установки и сопровождения приложения. Может также возникнуть ситуация, при которой приложение не находит свою DLL-библиотеку, несмотря на то, что нужная библиотека есть на диске.

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

3.3. Структура DLL-библиотеки

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

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

Функция LibEntry

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

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

Задачей функции LibEntry является инициализация локальной области памяти, если она определена для DLL-библиотеки.

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

Вам не надо определять функцию LibEntry самостоятельно, так как при создании файла DLL-библиотеки редактор связей, входящий в систему разработки, включит уже имеющийся в стандартной библиотеке модуль. Этот стандартный модуль выполняет всю необходимую работу по инициализации локальной области памяти DLL-библиотеки (с помощью функции LocalInit) и затем вызывает функцию LibMain, которая будет описана в следующем разделе.

Иногда для DLL-библиотеки может потребоваться нестандартная инициализация. Только в этом случае вам придется разработать функцию LibEntry самостоятельно. За основу вы можете взять файл libentry.asm из SDK, который содержит исходный текст упомянутой выше функции.

Функция LibMain

Функция LibMain должна присутствовать в каждой стандартной DLL-библиотеке. Эту функцию вам надо определить самостоятельно, причем вы можете воспользоваться языком программирования С.

По своему назначению функция LibMain напоминает функцию WinMain обычного приложения Windows. Функция WinMain получает управление при запуске приложения, а функция LibMain - при загрузке DLL-библиотеки в память. Так же как и функция WinMain, функция LibMain имеет параметры, которые можно использовать для инициализации библиотеки.

Приведем прототип функции LibMain :

int FAR PASCAL LibMain(HINSTANCE hInstance,
                       WORD wDataSegment,
                       WORD wHeapSize,
                       LPSTR lpszCmdLine);

Параметр hInstance при вызове функции содержит идентификатор DLL-библиотеки. Это ни что иное, как содержимое регистра DI перед вызовом функции LibEntry.

Через параметр wDataSegment передается селектор, соответствующий сегменту данных DLL-библиотеки. Если DLL-библиотека не имеет сегмента данных, этот параметр содержит идентификатор DLL-библиотеки (точнее, идентификатор модуля DLL-библиотеки). Значение параметра wDataSegment соответствует содержимому регистра DS перед вызовом функции LibEntry.

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

И, наконец, через параметр lpszCmdLine передается указатель на командную строку, которую можно передать DLL-библиотеке при ее явной загрузке в память.

Если инициализация DLL-библиотеки выполнена успешно, функция LibMain должна возвратить ненулевое значение. Если в процессе инициализации произошла ошибка, следует возвратить нуль. В этом случае функция LibEntry также возвратит нуль. Это приведет к тому, что Windows выгрузит библиотеку из памяти.

Разрабатывая процедуру инициализации DLL-библиотеки, учтите, что функция LibMain вызывается только один раз, во время загрузки библиотеки в память. Не следует думать, что для каждого приложения, использующего одну и ту же DLL-библиотеку, будет вызвана функция LibMain. При попытке повторной загрузки уже загруженной ранее DLL-библиотеки будет увеличено содержимое счетчика использования библиотеки, но и только.

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

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

Перед завершением работы приложение должно вызвать созданную вами функцию, освобождающую выделенную структуру данных. Она может называться, например, LibUnregister.

Если функция LibMain заказывает блоки памяти из глобальной области данных, следует использовать флаг GMEM_SHARE. Такие блоки памяти будут принадлежать создавшей их DLL-библиотеке. Освобождение заказанных глобальных блоков памяти можно выполнить в функции WEP, получающей управление при выгрузке DLL-библиотеки из памяти.

Приведем пример простейшего варианта функции LibMain:

int FAR PASCAL LibMain(HINSTANCE hInstance,
  WORD wDataSegment, WORD wHeapSize,
  LPSTR lpszCmdLine)
{
  if(wHeapSize != 0)
    UnlockData(0);
  return 1;
}

Эта функция проверяет размер локальной области данных, и если эта область данных существует, она расфиксируется при помощи макрокоманды UnlockData. После этого возвращается признак успешной инициализации.

Функция WEP

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

Приведем прототип функции WEP (при использовании системы разработки Borland Turbo C++ for Windows):

int FAR PASCAL WEP(int bSystemExit);

Параметр bSystemExit может принимать значения WEP_FREE_DLL и WEP_SYSTEM_EXIT . Этот параметр указывает причину выгрузки DLL-библиотеки из памяти. В первом случае выгрузка выполняется потому, что либо функциями библиотеки не пользуется ни одно приложение, либо одно из приложений выдало запрос на выгрузку. Если же параметр имеет значение WEP_SYSTEM_EXIT, выгрузка библиотеки происходит из-за завершения работы операционной системы Windows.

Функция WEP должна всегда возвращать значение 1.

Вам не обязательно самостоятельно определять функцию WEP. Так же как и функция LibEntry, функция WEP добавляется в DLL-библиотеку транслятором. Вы, однако, можете определить собственную функцию WEP, если перед выгрузкой DLL-библиотеки требуется освободить заказанные ранее блоки памяти.

Приведем пример простейшей функции WEP:

int FAR PASCAL WEP(int bSystemExit)
{
  return 1;
}

В операционной системе Windows версии 3.0 на использование функции WEP накладывались серьезные ограничения, которые делали ее практически бесполезной. Например, размер стека, используемого для работы этой функции, составлял всего 256 байт, чего совершенно недостаточно для вызова функций программного интерфейса Windows. Есть и другие проблемы, однако мы не будем их затрагивать из-за того, что версия 3.0 уже сильно устарела, а в версии 3.1 все эти ограничения сняты. Поэтому вы можете использовать функцию WEP для любых процедур, в частности, для освобождения памяти, полученной при инициализации в функции LibMain.

Экспортируемые функции

Кроме функций LibMain и WEP в DLL-библиотеке могут быть определены и другие функции (как мы уже говорили, существуют DLL-библиотеки, состоящие из одних ресурсов). Это могут быть экспортируемые и неэкспортируемые функции.

Экспортируемые функции доступны для вызова приложениям Windows. Неэкспортируемые являются локальными для DLL-библиотеки, они доступны только для функций библиотеки.

Самый простой способ сделать функцию экспортируемой в системе разработки Borland Turbo C++ for Windows - указать в ее определении ключевое слово _export. Мы использовали этот способ при определении функции окна. Для экспортируемой функции создается специальный пролог, необходимый для правильной загрузки сегментного регистра DS.

Есть и другой способ - можно перечислить все экспортируемые функции в файле определения модуля при помощи оператора EXPORTS :

EXPORTS
  DrawBitmap  @4
  ShowAll     
  HideAll
  GetMyPool   @8
  FreeMyPool  @9

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

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

Для ответа на этот вопрос следует знать, что ссылка на экспортируемую функцию может выполняться двумя различными способами - по имени функции и по ее порядковому номеру. Если функция вызывается по имени, ее порядковый номер не имеет значения. Однако вызов функции по порядковому номеру выполняется быстрее, поэтому использование порядковых номеров предпочтительнее.

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

Чтобы сказанное стало более понятным, рассмотрим подробнее механизм, с помощью которого приложения ссылаются на функции из DLL-библиотек.

Импортирование функций

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

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

Откуда при компоновке приложения редактор связей узнает имя DLL-библиотеки, имя или порядковый номер экспортируемой функции? Для динамической компоновки функции из DLL-библиотеки можно использовать различные способы.

Библиотека импорта

Для того чтобы редактор связей мог создать ссылку, в файл проекта приложения вы должны включить так называемую библиотеку импорта (import library ), созданную приложением Import Lib , входящим в состав системы разработки Borland Turbo C++ for Windows. Соответствующее средство имеется в SDK, а также в любой другой системе разработки приложений Windows.

Библиотека импорта создается либо на основе dll-файла библиотеки, либо на основе файла определения модуля, используемого для создания DLL-библиотеки.

В любом случае вам надо запустить приложение Import Lib, и из меню "File" выбрать строку "File Select...". При этом на экране появится диалоговая панель "Select File", с помощью которой вы можете выбрать нужный вам dll- или def-файл (рис. 3.6).

Рис. 3.6. Работа с приложением Import Library

После выбора файла приложение Import Lib создаст библиотеку импорта в виде lib-файла, расположенного в том же каталоге, что и исходный dll- или def-файл. Этот файл необходимо включить в проект создаваемого вами приложения, пользующегося функциями DLL-библиотеки.

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

В состав системы разработки Borland C++ for Windows версии 4.0 и 4.01 входит DLL-библиотека, содержащая функции стандартной библиотеки компилятора. Эта библиотека расположена в файле с именем bc40rtl.dll. В проекте приложения вы можете определить, что для стандартных функций следует использовать динамическую компоновку. В этом случае размер полученного загрузочного модуля заметно сократится, однако для работы приложения будет нужен файл bc40rtl.dll.

Использование оператора IMPORTS

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

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

IMPORTS
  Msg=dllsrc.4
  dllsrc.TellMe

Во второй строке приведенного выше примера приложение импортирует функцию Msg из DLL-библиотеки dllsrc.dll, причем порядковый номер указанной функции в библиотеке равен 4.

В третьей строке из DLL-библиотеки dllsrc.dll импортируется функция с именем TellMe, причем ее порядковый номер не используется.

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

Динамический импорт функций во время выполнения приложения

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

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

Однако приложение может в любой момент времени загрузить любую DLL-библиотеку, вызвав специально предназначенную для этого функцию программного интерфейса Windows с именем LoadLibrary . Приведем ее прототип:

HINSTANCE WINAPI LoadLibrary(LPCSTR lpszLibFileName);

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

текущий каталога;

каталог, в котором находится операционная система Windows;

системный каталог Windows;

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

каталоги, перечисленные в операторе описания среды PATH, расположенном в файле autoexec.bat;

каталоги, расположенные в сети, если для них определены пути поиска.

Если файл DLL-библиотеки найден, функция LoadLibrary возвращает идентификатор модуля библиотеки. В противном случае возвращается код ошибки, который по своему значению меньше величины HINSTANCE_ERROR, определенной в файле windows.h. Возможны следующие коды ошибок:

Функция LoadLibrary может быть вызвана разными приложениями для одной и той же DLL-библиотеки несколько раз. В этом случае загрузка DLL-библиотеки выполняется только один раз. Последующие вызовы функции LoadLibrary приводят только к увеличению счетчика использования DLL-библиотеки.

В качестве примера приведем фрагмент исходного текста приложения, загружающего DLL-библиотеку из файла srcdll.dll:

HINSTANCE hLib;
hLib = LoadLibrary("srcdll.dll");
if(hLib >= HINSTANCE_ERROR)
{
  // Работа с DLL-библиотекой
}
FreeLibrary(hLib);

Если DLL-библиотека больше не нужна, ее следует освободить с помощью функции FreeLibrary :

void WINAPI FreeLibrary(HINSTANCE hLibrary);

В качестве параметра этой функции следует передать идентификатор освобождаемой библиотеки.

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

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

Для того чтобы вызвать функцию из библиотеки, зная ее идентификатор, необходимо получить значение дальнего указателя на эту функцию, вызвав функцию GetProcAddress :

FARPROC WINAPI GetProcAddress(HINSTANCE hLibrary, 
  LPCSTR lpszProcName);

Через параметр hLibrary вы должны передать функции идентификатор DLL-библиотеки, полученный ранее от функции LoadLibrary.

Параметр lpszProcName является дальним указателем на строку, содержащую имя функции или ее порядковый номер, преобразованный макрокомандой MAKEINTRESOURCE.

Приведем фрагмент кода, в котором определяются адреса двух функций. В первом случае используется имя функции, а во втором - ее порядковый номер:

FARPROC lpMsg;
FARPROC lpTellMe;
lpMsg = GetProcAddress(hLib, "Msg");
lpTellMe = GetProcAddress(hLib, MAKEINTRESOURCE(8));

Перед тем как передать управление функции по полученному адресу, следует убедиться в том, что этот адрес не равен NULL:

if(lpMsg != (FARPROC)NULL)
{
  (*lpMsg)((LPSTR)"My message");
}

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

typedef int (FAR PASCAL *LPGETZ)(int x, int y);
LPGETZ lpGetZ;
lpGetZ = (LPGETZ)GetProcAddress(hLib, "GetZ");

А что произойдет, если приложение при помощи функции LoadLibrary попытается загрузить DLL-библиотеку, которой нет на диске?

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

Для того чтобы отключить режим вывода диалоговой панели с сообщением о невозможности загрузки DLL-библиотеки, вы можете использовать функцию SetErrorMode , передав ей в качестве параметра значение SEM_NOOPENFILEERRORBOX .

Приведем прототип функции SetErrorMode:

UINT WINAPI SetErrorMode(UINT fuErrorMode);

Эта функция позволяет отключать встроенный в Windows обработчик прерывания MS-DOS INT 24h (критическая ошибка). В качестве параметра этой функции можно указывать комбинацию следующих значений:

Функция SetErrorMode возвращает предыдущий режим обработки ошибки.

Файл определения модуля для DLL-библиотеки

Файл определения модуля для DLL-библиотеки отличается от соответствующего файла обычного приложения Windows. В качестве примера приведем образец такого файла:

LIBRARY     DLLNAME
DESCRIPTION 'DLL-библиотека DLLNAME'
EXETYPE     windows
CODE        moveable discardable
DATA        moveable single
HEAPSIZE    1024
EXPORTS
  DrawBitmap  @4
  ShowAll     
  HideAll
  GetMyPool   @8
  FreeMyPool  @9

В файле определения модуля DLL-библиотеки вместо оператора NAME должен находиться оператор LIBRARY , определяющий имя модуля DLL-библиотеки, под которым она будет известна Windows.

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

Оператор CODE используется для определения атрибутов сегмента кода DLL-библиотеки.

Особенностью оператора DATA является использование параметра SINGLE. Так как DLL-библиотека находится в памяти в единственном экземпляре и может иметь только один сегмент данных, для описания сегмента данных библиотеки требуется параметр SINGLE.

Оператор HEAPSIZE определяет начальное значение локальной области памяти, которая будет выделена для DLL-библиотеки функцией LibEntry на этапе инициализации. Если DLL-библиотека не должна иметь локальную область данных, в качестве параметра следует указать нулевое значение:

HEAPSIZE 0

И, наконец, оператор EXPORTS предназначен для перечисления имен и порядковых номеров функций, экспортируемых DLL-библиотекой.

Анализ DLL-библиотек при помощи утилиты tdump.exe

В комплекте системы разработки Borland Turbo C++ for Windows входит утилита tdump.exe , предназначенная для работы в среде MS-DOS. С помощью этой утилиты вы сможете проанализировать содержимое любой DLL-библиотеки, определив имена экспортируемых функций, их порядковые номера, имена DLL-библиотек и номера функций, импортируемых из этих библиотек и т. д.

В системном каталоге Windows имеется DLL-библиотека toolhelp.dll, предназначенная для создания отладочных средств и работы с внутренними структурами данных Windows. Мы выбрали эту библиотеку для наших исследований в основном из-за ее небольшого размера. Описание самой библиотеки выходит за рамки данного тома "Библиотеки системного программиста".

Итак, скопируйте библиотеку в любой временный каталог и введите в среде MS-DOS (или в среде виртуальной машины MS-DOS) следующую команду:

tdump toolhelp.dll toolhelp.map

В результате в файл toolhelp.map будет записано подробное описание библиотеки toolhelp.dll. Мы приведем полученный листинг с нашими комментариями.

Turbo Dump  Version 3.1 Copyright (c) 1988, 1992 Borland International
                   Display of File TOOLHELP.DLL

В начале файла DLL-библиотеки находится заголовок в формате MS-DOS. Он нас не интересует.

Old Executable Header

DOS File Size                               3730h  ( 14128. )
Load Image Size                              359h  (   857. )
Relocation Table entry count                0000h  (     0. )
Relocation Table address                    0040h  (    64. )
Size of header record      (in paragraphs)  0004h  (     4. )
Minimum Memory Requirement (in paragraphs)  0000h  (     0. )
Maximum Memory Requirement (in paragraphs)  FFFFh  ( 65535. )
File load checksum                          0000h  (     0. )
Overlay Number                              0000h  (     0. )

Initial Stack Segment  (SS:SP)   0000:00B8
Program Entry Point    (CS:IP)   0000:0000

Далее в листинге приводится информация о заголовке загрузочного файла в формате Windows. Это так называемый заголовок нового исполняемого формата.

New Executable header
Operating system                                    Windows
File Load CRC                                       0AABAA86Bh
Program Entry Point   (CS:IP)      0001:016A
Initial Stack Pointer (SS:SP)      0000:0000
Auto Data Segment Index            0002h  (     2. )
Initial Local Heap Size            0200h  (   512. )
Initial Stack Size                 0000h  (     0. )
Segment count                      0002h  (     2. )
Module reference count             0002h  (     2. )
Moveable Entry Point Count         0000h  (     0. )
File alignment unit size           0010h  (    16. )
DOS File Size                      3730h  ( 14128. )
Linker Version                     5.20

Обратите внимание, что в заголовке присутствует информация об адресе точки входа (Program entry Point). Начальное содержимое указателя стека (Initial Stack Pointer) равно нулю, так же как и начальный размер стека (Initial Stack Size). Это понятно, так как DLL-библиотека не имеет собственного стека.

В то же время начальный размер локальной области данных отличен от нуля и равен 512 байт (Initial Local Heap Size). Из заголовка можно также определить, что модуль DLL-библиотеки состоит из двух сегментов (Segment Count).

Далее в листинге приведены различные флаги. В частности, видно, что сегмент данных DGROUP имеет атрибуты single и может использоваться совместно различными приложениями (shared). Данный модуль может работать только в защищенном режиме (Protected mode only) и является ни чем иным, как DLL-библиотекой (Module type - Dynamic link Library(DLL)).

Program Flags
    DGROUP                 : single (shared)
    Global initializaton   : No 
    Protected mode only    : Yes
    Application type       : Uses windowing API
    Self Loading           : No 
    Errors in image        : No 
    Module type            : Dynamic link Library (DLL)
Other EXE Flags
    2.X protected mode     : No 
    2.X proportional font  : No 
    Gangload area          : Yes
Start of Gangload Area                              03E0h
Length of Gangload Area                             3160h
Miminum code swap area size                         0
Expected Windows Version                            3.00

Затем в листинге перечисляются различные таблицы с указанием их смещения и размера:

Segment Table                Offset: 00C0h     Length: 0010h
Resource Table               Offset: 00D0h    Length: 0018h
Resident Names Table         Offset: 00E8h      Length: 0012h
Module Reference Table       Offset: 00FAh    Length: 0004h
Imported Names Table         Offset: 00FEh      Length: 000Dh
Entry Table                  Offset: 010Bh       Length: 0070h
Nonresident Names Table      Offset: 017Bh   Length: 0236h

Это таблица сегментов. В ней описаны два сегмента. Первый сегмент является сегментом кода, второй - сегментом данных.

Segment Table                   offset: 00C0h

    Segment Number: 01h
    Segment Type:   CODE     Alloc Size : 2EEEh
    Sector Offset:  0040h   File length: 2EEEh
    Attributes: Preloaded  Relocations  

    Segment Number: 02h
    Segment Type:   DATA     Alloc Size : 0120h
    Sector Offset:  033Eh   File length: 0120h
    Attributes: Sharable  Preloaded  

Далее приводится информация о ресурсах DLL-библиотеки. Таблица ресурсов описывает единственный ресурс типа Version info, описывающий версию модуля.

Resource Table                  offset: 00D0h

    Sector size: 0010h

    type: Version info
          Identifier: 1             
              offset: 03540h length: 01F0h
          Attributes: Moveable   Shareable       

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

Resident Name Table             offset: 00E8h
    Module Name: 'TOOLHELP'
    Name: WEP                          Entry: 0001

Таблица ссылок на модули содержит имена модулей (DLL-библиотек), на которые ссылаются функции, расположенные в исследуемой библиотеке. Как видно из листинга, функции библиотеки toolhelp.dll ссылаются на модули KERNEL и USER. Эти модули являются основными компонентами операционной системы Windows и расположены, соответственно, в файлах krnl386.exe, krnl286.exe и user.exe.

Module Reference Table          offset: 00FAh
    Module  1: KERNEL                                  
    Module  2: USER                                    


Imported Names Table            offset: 00FEh
    name                               offset
    KERNEL                              0001h
    USER                                0008h

Таблица входов (Entry Table) описывает экспортируемые функции. Для каждой функции приводится ее порядковый номер и смещение.

Entry Table                     offset: 010Bh
  Fixed Segment Records  (  1 Entries)    Segment: 0001h
    Entry    1: Offset: 018Ah   Exported   Single data

  Null Entries: 48

  Fixed Segment Records  ( 34 Entries)   Segment: 0001h
    Entry   50: Offset: 057Bh   Exported   Single data
    Entry   51: Offset: 0318h   Exported   Single data
    Entry   52: Offset: 0399h   Exported   Single data
    Entry   53: Offset: 02A2h   Exported   Single data
    Entry   54: Offset: 0417h   Exported   Single data
    Entry   55: Offset: 04A9h   Exported   Single data
    Entry   56: Offset: 090Eh   Exported   Single data
    Entry   57: Offset: 095Eh   Exported   Single data
    Entry   58: Offset: 09E9h   Exported   Single data
    Entry   59: Offset: 0A90h   Exported   Single data
    Entry   60: Offset: 0AD9h   Exported   Single data
    Entry   61: Offset: 0B15h   Exported   Single data
    Entry   62: Offset: 0B8Ch   Exported   Single data
    Entry   63: Offset: 0CAAh   Exported   Single data
    Entry   64: Offset: 0CEDh   Exported   Single data
    Entry   65: Offset: 0D2Eh   Exported   Single data
    Entry   66: Offset: 0F1Ch   Exported   Single data
    Entry   67: Offset: 0F67h   Exported   Single data
    Entry   68: Offset: 0FCAh   Exported   Single data
    Entry   69: Offset: 28B0h   Exported   Single data
    Entry   70: Offset: 2925h   Exported   Single data
    Entry   71: Offset: 11CEh   Exported   Single data
    Entry   72: Offset: 13F4h   Exported   Single data
    Entry   73: Offset: 1B72h   Exported   Single data
    Entry   74: Offset: 1C29h   Exported   Single data
    Entry   75: Offset: 2060h   Exported   Single data
    Entry   76: Offset: 2111h   Exported   Single data
    Entry   77: Offset: 26EAh   Exported   Single data
    Entry   78: Offset: 29C4h   Exported   Single data
    Entry   79: Offset: 2B6Ch   Exported   Single data
    Entry   80: Offset: 2DAEh   Exported   Single data
    Entry   81: Offset: 0D68h   Exported   Single data
    Entry   82: Offset: 0D97h   Exported   Single data
    Entry   83: Offset: 0DC0h   Exported   Single data

Имена и порядковые номера экспортируемых функций приведены в таблице нерезидентных имен (Non-Resident Name Table):

Non-Resident Name Table         offset: 017Bh
    Module Description: 'TOOLHELP - Debug/Tool Helper library'
    Name: TASKSETCSIP                  Entry:    81
    Name: MEMMANINFO                   Entry:    72
    Name: STACKTRACEFIRST              Entry:    66
    Name: MEMORYWRITE                  Entry:    79
    Name: GLOBALINFO                   Entry:    53
    Name: TASKNEXT                     Entry:    64
    Name: CLASSNEXT                    Entry:    70
    Name: GLOBALENTRYHANDLE            Entry:    54
    Name: GLOBALHANDLETOSEL            Entry:    50
    Name: INTERRUPTREGISTER            Entry:    75
    Name: STACKTRACECSIPFIRST          Entry:    67
    Name: LOCALNEXT                    Entry:    58
    Name: INTERRUPTUNREGISTER          Entry:    76
    Name: MODULENEXT                   Entry:    60
    Name: LOCALINFO                    Entry:    56
    Name: TASKFINDHANDLE               Entry:    65
    Name: TASKSWITCH                   Entry:    83
    Name: MEMORYREAD                   Entry:    78
    Name: NOTIFYREGISTER               Entry:    73
    Name: GLOBALNEXT                   Entry:    52
    Name: TIMERCOUNT                   Entry:    80
    Name: MODULEFINDHANDLE             Entry:    62
    Name: MODULEFIRST                  Entry:    59
    Name: GLOBALENTRYMODULE            Entry:    55
    Name: STACKTRACENEXT               Entry:    68
    Name: GLOBALFIRST                  Entry:    51
    Name: SYSTEMHEAPINFO               Entry:    71
    Name: TERMINATEAPP                 Entry:    77
    Name: TASKFIRST                    Entry:    63
    Name: NOTIFYUNREGISTER             Entry:    74
    Name: TASKGETCSIP                  Entry:    82
    Name: CLASSFIRST                   Entry:    69
    Name: MODULEFINDNAME               Entry:    61
    Name: LOCALFIRST                   Entry:    57

Далее в листинге описываются ссылки на импортируемые модули. Каждая такая ссылка состоит из имени модуля (в нашем случае это KERNEL или USER) и порядкового номера импортируемой функции. Сделав дамп файла krnl386.exe при помощи утилиты tdump.exe, вы сможете определить, что ссылке KERNEL.3 соответствует функция GetVersion, ссылке KERNEL.4 - функция LocalInit, а ссылке KERNEL.5 - функция LocalAlloc.

Segment Relocation Records

    Segment 0001h relocations

    type    offset    target
    BASE    2BBBh     0001h:0000h
    BASE    2E93h     0002h:0000h
    PTR     020Fh     KERNEL.3   
    PTR     0177h     KERNEL.4   
    PTR     27D9h     KERNEL.5   
    PTR     28A5h     KERNEL.7   
    PTR     2761h     KERNEL.137 
    OFFS    2D47h     KERNEL.114 
    BASE    0214h     KERNEL.18  
    PTR     2E66h     USER.13  
    PTR     0E2Bh     KERNEL.150 
    PTR     01EAh     KERNEL.28  
    PTR     27B0h     KERNEL.36  
    PTR     23E5h     KERNEL.170 
    PTR     223Dh     KERNEL.47  
    PTR     23FDh     KERNEL.176 
    PTR     224Fh     KERNEL.50  
    PTR     0B66h     USER.430 
    PTR     28F6h     USER.179 
    PTR     29A5h     KERNEL.72  
    OFFS    2EC1h     KERNEL.178 
    PTR     1D79h     KERNEL.202 
    OFFS    27EFh     0001h:16C5h
    LOBYTE  2ACEh     KERNEL.114  additive
    LOBYTE  2CA4h     KERNEL.114  additive
    Relocations: 25

3.4. Приложение DLLCALL

Исходный текст простейшей DLL-библиотеки приведен в листинге 3.1. Как видно из листинга, в библиотеке определены всего три функции - LibMain, WEP и Msg.

Листинг 3.1. Файл dllcall/dllsrc.cpp

#define  STRICT
#include <windows.h>

// ========================================================
// Функция LibMain
// Получает управление только один раз при
// загрузке DLL-библиотеки в память
// ========================================================

#pragma argsused
int FAR PASCAL LibMain(HINSTANCE hInstance,
                       WORD wDataSegment,
                       WORD wHeapSize,
                       LPSTR lpszCmdLine)
{
  // После инициализации локальной области данных
  // функция LibEntry фиксирует сегмент данных.
  // Его необходимо расфиксировать.
  if(wHeapSize != 0)
    // Расфиксируем сегмент данных
    UnlockData(0);

  // Возвращаем 1. Это означает, что инициализация
  // DLL-библиотеки выполнена успешно
  return 1;
}

// ========================================================
// Функция WEP
// Получает управление только один раз при
// удалении DLL-библиотеки из памяти
// ========================================================

#pragma argsused
int FAR PASCAL WEP(int bSystemExit)
{
  return 1;
}

// ========================================================
// Функция Msg
// Выводит на экран диалоговую панель с сообщением
// ========================================================

void FAR PASCAL _export Msg(LPSTR lpszMsg)
{
  MessageBox(NULL, lpszMsg, "DLLSRC", MB_OK);
}

Функция LibMain проверяет размер локальной области данных, заказанной для DLL-приложения функцией LibEntry. Этот размер определяется значением, указанным в файле определения модуля DLL-библиотеки при помощи оператора HEAPSIZE и передается функции LibMain через параметр wHeapSize. Если DLL-библиотека имеет локальную область данных, на этапе инициализации ее необходимо расфиксировать для того чтобы разрешить Windows при необходимости произвольно изменять логический адрес сегмента данных в процессе перемещения сегментов. Использованный способ расфиксирования сегмента данных был описан в предыдущей главе и основан на использовании макрокоманды UnlockData.

После инициализации, которая в нашем простейшем примере всегда выполняется успешно, функция WinMain возвращает признак успешной инициализации - значение 1.

Задача функции WEP в нашем случае сводится к возврату значения 1, означающего успешное завершение.

Функция Msg - единственная функция предназначена для вывода строки сообщения, адрес которой передается ей в качестве параметра. Так как эта функция определена с ключевым словом _export, она может быть вызвана любым приложением. Именно эту функцию мы будем вызывать из приложения DLLCALL, исходные тексты которого приведены ниже.

Файл определения модуля для DLL-библиотеки имеет некоторые особенности (листинг 3.2).

Листинг 3.2. Файл dllcall/dll.def

; =============================
; Файл определения модуля
; =============================
LIBRARY        DLLSRC
DESCRIPTION    'DLL-библиотека DLLSRC, (C) 1994, Frolov A.V.'
EXETYPE        windows
CODE           preload moveable discardable
DATA           preload moveable single
HEAPSIZE       1024

Во-первых, в нем нет оператора NAME, предназначенного для идентификации приложения. Вместо него используется оператор LIBRARY. Этот оператор указывает, что данный файл описывает не приложение, а DLL-библиотеку.

Во-вторых, в операторе DATA указан параметр single, так как в памяти может находиться только одна копия DLL-библиотеки и, соответственно, может существовать только один сегмент данных.

И в-третьих, в файле определения модуля нет оператора STACKSIZE, так как DLL-библиотека не может иметь стек.

Для создания библиотеки вы можете воспользоваться файлом dllsrc.prj, который есть на дискете, продаваемой вместе с книгой в каталоге dllcall.

В файла проекта DLL-библиотеки, сделанной с помощью системы разработки Borland Turbo C++ for Windows, вам необходимо указать правильный тип приложения. Для этого в меню "Options" выберите строку "Application..." и в появившейся не экране диалоговой панели "Application Options" нажмите на кнопку "Windows DLL" (рис. 3.7). После этого нажмите на кнопку "OK".

Рис. 3.7. Диалоговая панель "Application Options"

Обратите внимание на то, что по умолчанию при создании DLL-библиотеки все функции, определенные в ней, становятся экспортируемыми (Windows DLL all functions exportable). Это означает, что все функции, определенные вами в DLL-библиотеке, имеют специальный пролог и эпилог, предназначенный для правильной загрузки регистра DS (в этот регистр записывается селектор сегмента данных DLL-библиотеки). Кроме того, все эти функции перечисляются в заголовке загрузочного dll-файла библиотеки.

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

Исходный текст приложения DLLCALL, вызывающего функцию Msg из нашей DLL-библиотеки, приведен в листинге 3.3.

Листинг 3.3. Файл dllcall/dllcall.cpp

// ----------------------------------------
// Вызов функции, расположенной в
// DLL-библиотеке
// ----------------------------------------

#define STRICT
#include <windows.h>

// Объявление функции, расположенной в DLL-библиотеке
extern void FAR PASCAL Msg(LPSTR lpszMsg);

// =====================================
// Функция WinMain
// =====================================
#pragma argsused

int PASCAL
WinMain(HINSTANCE hInstance, 
        HINSTANCE hPrevInstance,
        LPSTR     lpszCmdLine, 
        int       nCmdShow)
{
  // Вызываем функцию из DLL-библиотеки
  Msg((LPSTR)"Вам привет из DLL!");

  return 0;
}

Обратите внимание на то, что функция Msg описана как внешняя:

extern void FAR PASCAL Msg(LPSTR lpszMsg);

Файл определения модуля для приложения DLLCALL приведен в листинге 3.4. Он не имеет никаких особенностей.

Листинг 3.4. Файл dllcall/dllcall.def

; =============================
; Файл определения модуля
; =============================
NAME        DLLCALL
DESCRIPTION 'Приложение DLLCALL, (C) 1994, Frolov A.V.'
EXETYPE     windows
STUB        'winstub.exe'
STACKSIZE   8120
HEAPSIZE    1024
CODE        preload moveable discardable
DATA        preload moveable multiple

Файл проекта приложения DLLCALL включает в себя библиотеку импорта dllsrc.lib, которую мы сделали из DLL-библиотеки dllsrc.dll при помощи приложения Import Lib, входящего в состав системы разработки Borland Turbo C++ for Windows.

3.5. Приложение DISCARD

В предыдущей главе мы приводили исходные тексты приложений GMEM и LMEM, которые, кроме всего прочего, демонстрировали приемы работы с удаляемой памятью. В этих приложениях мы заказывали удаляемые блоки памяти из, соответственно, глобальной и локальной области памяти, удаляли их а затем пытались зафиксировать, чтобы получить их линейный адрес. Так как блоки памяти были удалены, нам приходилось их восстанавливать.

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

Теперь, когда мы умеем создавать свои DLL-библиотеки, мы можем испытать работу механизма оповещения о попытке удаления глобального блока памяти .

Приложение DISCARD (листинг 3.5), сделанное на базе приложения GMEM, заказывает удаляемый блок памяти и назначает собственную процедуру извещения об удалении глобальных блоков памяти. Процедура размещена в DLL-библиотеке dll.dll, исходные тексты которой мы также приведем.

Листинг 3.5. Файл discard/discard.cpp

#define STRICT
#include <windows.h>
#include <windowsx.h>
#include <dos.h>

// Прототип функции извещения о том, что Windows
// планирует удалить блок памяти
// Так как функция NotifyProc составлена на языке
// программирования C (а не C++), мы описываем ее
// как extern "C"   
extern "C" BOOL CALLBACK _export NotifyProc(HGLOBAL hglbl);

#pragma argsused
int PASCAL
WinMain(HINSTANCE hInstance,
   HINSTANCE hPrevInstance,
   LPSTR     lpszCmdLine, int nCmdShow)
{
  BYTE szBuf[100];
  HGLOBAL hmemGlDiscard;
  LPVOID  lpvoidGlobal;
  LPVOID  lpvoidGlDiscard;
  DWORD   dwMaxFreeMem;

  // Определяем размер доступной памяти
  dwMaxFreeMem = GlobalCompact(-1l);

  wsprintf(szBuf, "Доступно памяти:\t%lu\n",
        dwMaxFreeMem);
  MessageBox(NULL, (LPSTR)szBuf, "Global Block", MB_OK);

  // Устанавливаем процедуру извещения, которая
  // получит управление при попытке удалить
  // блок памяти 
  GlobalNotify((GNOTIFYPROC)NotifyProc);

  // Заказываем удаляемый блок памяти размером 200000 байт
  // Для включения режима извещения необходимо
  // указать флаг GMEM_NOTIFY
  hmemGlDiscard =
      GlobalAlloc(GMEM_MOVEABLE | GMEM_DISCARDABLE 
       | GMEM_NOTIFY, 200000l);

  if(hmemGlDiscard != NULL)
  {
    // Если мы его получили, пытаемся удалить блок
    GlobalDiscard(hmemGlDiscard);

    // Фиксируем блок памяти
    lpvoidGlDiscard = GlobalLock(hmemGlDiscard);

    if(lpvoidGlDiscard != (LPVOID) NULL)
    {
      // Так как наша процедура извещения запрещает
      // удаление блока, попытка его фиксирования
      // должна закончится успешно. В этом случае
      // мы выводим идентификатор блока памяти и его
      // логический адрес
      wsprintf(szBuf, "hmemGlDiscard=\t%04.4X\n"
        "lpvoidGlDiscard=\t%04.4X:%04.4X",
        hmemGlDiscard,
        FP_SEG(lpvoidGlDiscard), FP_OFF(lpvoidGlDiscard));
      MessageBox(NULL, (LPSTR)szBuf, "Global Block", MB_OK);

      // Разрешаем перемещение блока
      GlobalUnlock(hmemGlDiscard);
    }
    else
    {
      // Если блок памяти не удалось зафиксировать,
      // проверяем, не был ли он удален
      if(GlobalFlags(hmemGlDiscard) & GMEM_DISCARDED)
      {
         // Так как мы запретили удаление блока, следующее
         // сообщение не должно появиться на экране
         MessageBox(NULL, "Блок удален и мы его"
           " восстанавливаем",
           "Global Block", MB_OK);

         // Восстанавливаем удаленный блок памяти
         hmemGlDiscard = GlobalReAlloc(hmemGlDiscard,
           200000l,
           GMEM_MOVEABLE | GMEM_DISCARDABLE);

         // Фиксируем блок памяти
         lpvoidGlDiscard = GlobalLock(hmemGlDiscard);

         if(lpvoidGlDiscard != (LPVOID) NULL)
         {
           // Выводим идентификатор и логический адрес
           // зафиксированного блока памяти
           wsprintf(szBuf, "hmemGlDiscard=\t%04.4X\n"
             "lpvoidGlDiscard=\t%04.4X:%04.4X",
             hmemGlDiscard,
             FP_SEG(lpvoidGlDiscard),
             FP_OFF(lpvoidGlDiscard));
           MessageBox(NULL, (LPSTR)szBuf, "Global Block",
             MB_OK);

           // Освобождаем блок памяти
           GlobalUnlock(hmemGlDiscard);
         }
         else
         {
           MessageBox(NULL, "Ошибка при фиксировании блока",
           "Global Block", MB_OK);
         }
      }
    }

    // Отдаем удаляемый блок памяти операционной системе
    GlobalFree(hmemGlDiscard);
  }
  else
  {
    MessageBox(NULL, "Мало памяти для удаляемого блока",
      "Global Block", MB_OK);
  }
  return 0;
}

DLL-библиотека, в которой расположена функция извещения, составлена нами с использованием языка программирования C, а не C++. Это сделано для упрощения экспортирования функции, которая в данном случае экспортируется с использованием своего порядкового номера. Подробнее этот вопрос мы рассмотрим при описании исходного текста DLL-библиотеки, а пока заметим, что так как для функции извещения использован язык C, мы должны это отметить в прототипе функции, включаемой в исходный текст приложения, составленного на языке C++:

extern "C" BOOL CALLBACK _export NotifyProc(HGLOBAL hglbl);

После запуска приложения функция WinMain определяет размер доступной памяти, вызывая функцию GlobalCompact, а затем выводит его на экран.

После этого функция WinMain устанавливает процедуру извещения, вызывая функцию GlobalNotify и передавая ей в качестве параметра адрес внешней по отношению к приложению функции извещения NotifyProc, расположенной в DLL-библиотеке:

GlobalNotify((GNOTIFYPROC)NotifyProc);

Каждая копия приложения может вызывать функцию GlobalNotify только один раз.

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

После установки функции извещения приложение заказывает удаляемый блок памяти, указывая среди прочих флаг GMEM_NOTIFY :

hmemGlDiscard =
  GlobalAlloc(GMEM_MOVEABLE | GMEM_DISCARDABLE 
  | GMEM_NOTIFY, 200000l);

Если этот флаг не будет указан, Windows при необходимости удалит блок без вызова процедуры извещения.

После получения блока памяти приложение пытается его удалить, вызывая функцию GlobalDiscard (можно было бы, конечно, подождать, пока этот блок будет удален самой операционной системой Windows, однако вы можете прождать до утра):

GlobalDiscard(hmemGlDiscard);

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

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

Файл определения модуля приложения DISCARD приведен в листинге 3.6.

Листинг 3.6. Файл discard/discard.def

; =============================
; Файл определения модуля
; =============================
NAME        DISCARD
DESCRIPTION 'Приложение DISCARD, (C) 1994, Frolov A.V.'
EXETYPE     windows
STUB        'winstub.exe'
STACKSIZE   8120
HEAPSIZE    1024
CODE        preload moveable discardable
DATA        preload moveable multiple

Исходный текст DLL-библиотеки приведен в листинге 3.7.

Листинг 3.7. Файл discard/dll.c

#define  STRICT
#include <windows.h>

// ========================================================
// Функция LibMain
// Получает управление только один раз при
// загрузке DLL-библиотеки в память
// ========================================================

#pragma argsused
int FAR PASCAL LibMain(HINSTANCE hInstance,
                       WORD wDataSegment,
                       WORD wHeapSize,
                       LPSTR lpszCmdLine)
{
  // После инициализации локальной области данных
  // функция LibEntry фиксирует сегмент данных.
  // Его необходимо расфиксировать.
  if(wHeapSize != 0)
    // Расфиксируем сегмент данных
    UnlockData(0);

  // Возвращаем 1. Это означает, что инициализация
  // DLL-библиотеки выполнена успешно
  return 1;
}

// ========================================================
// Функция WEP
// Получает управление только один раз при
// удалении DLL-библиотеки из памяти
// ========================================================

#pragma argsused
int FAR PASCAL WEP(int bSystemExit)
{
  return 1;
}

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

#pragma argsused
BOOL FAR PASCAL _export NotifyProc(HGLOBAL hglbl)
{
  return 0;
}

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

Изучение последней также не вызовет ни малейшего затруднения. Функция NotifyProc возвращает значение 0, запрещая Windows удалять блок памяти. Если надо разрешить удаление блока памяти, необходимо вернуть значение 1.

Обратим внимание на файл определения модуля DLL-библиотеки, приведенный в листинге 3.8.

Листинг 3.8. Файл discard/dll.def

; =============================
; Файл определения модуля
; =============================
LIBRARY        DLL
DESCRIPTION    'DLL-библиотека DLL, (C) 1994, Frolov A.V.'
EXETYPE        windows
CODE           preload fixed
DATA           preload moveable single
HEAPSIZE       1024
EXPORTS
  NotifyProc @10

Исходя из требований функции извещения, сегмент кода DLL-библиотеки сделан фиксированным. Кроме того, мы использовали оператор EXPORTS для экспортирования функции извещения и задали для этой функции порядковый номер.

Теперь о том, почему для создания DLL-библиотеки мы выбрали язык C, а не С++.

Как вы знаете, трансляторы языка C++ "разукрашивают" имена функций в объектном модуле, добавляя к ним символы, обозначающие типы аргументов и тип возвращаемого значения. Когда в файле определения модуля в разделе EXPORTS мы перечисляем имена функций, при сборке загрузочного файла DLL-библиотеки редактор связей будет искать в объектном модуле функции с перечисленными именами. Если же исходный текст составлен на языке C++, имена, расположенные в объектном модуле, будут мало напоминать использованные в исходном тексте. В результате редактор связей выведет сообщение о том, что он не может найти в объектном модуле указанные в файле определения модуля экспортируемые функции.

Если же исходный текст DLL-библиотеки составлен на языке C, эти проблемы исчезнут. Однако в этом случае при вызове таких экспортируемых функций из приложений, составленных на языке C++, вам придется объявить их как extern "C".

Если же для разработки DLL-библиотеки используется язык C++, для обеспечения доступа к экспортируемым функциям вы можете либо использовать библиотеку импорта, созданную приложением IMPLIB, либо описать экспортируемую функцию следующим образом (в качестве примера использован исходный текст одной из функций DLL-библиотеки, описанной в разделе "Приложение WINHOOK"):

extern "C"
void WINAPI _export RemoveKbHook(void)
{
  if(bHooked)
  {
    UnhookWindowsHookEx(hhookMsg);
    UnhookWindowsHookEx(hhook);
  }
}

Описание extern "C" отменяет для определяемой функции соглашение языка C++ об именах функций.

3.6. Фильтры

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

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

Для чего можно использовать фильтры?

С помощью фильтров вы можете перехватить сообщения, поступающие в любые диалоговые панели, полосы просмотра, меню и т. п., причем как для отдельного приложения, так и для всех приложений сразу. Можно "отобрать" сообщения у функций GetMessage, PeekMessage, SendMessage. Можно записывать и затем проигрывать события, связанные с перемещением мыши и использованием клавиатуры. Фильтры облегчают создание обучающих приложений, которые работают совместно с обычными приложениями Windows в режиме обучения. Обучающие приложения может контролировать действия пользователя, когда он работает с приложением.

В качестве примера в разделе "Приложение WINHOOK" мы расскажем вам о том, как можно с помощью фильтров переключать раскладку клавиатуры. Мы приведем исходные тексты несложного руссификатора клавиатуры, позволяющего использовать в операционной системе Windows символы кириллицы.

Установка фильтра

Для установки фильтра в операционной системе Windows версии 3.1 следует использовать функцию SetWindowsHookEx (в Windows версии 3.0 для этой цели была предназначена функция SetWindowsHook ):

HHOOK WINAPI SetWindowsHookEx(
  int idHook,            // тип фильтра
  HOOKPROC lpfn,         // адрес функции фильтра
  HINSTANCE hInstance,   // идентификатор приложения
  HTASK hTask); // задача, для которой устанавливается фильтр

Параметр idHook определяет тип встраиваемого фильтра. В качестве значения для этого параметра можно использовать одну из следующих констант:

Параметр lpfn функции SetWindowsHookEx должен определять адрес функции встраиваемого фильтра (или, иными словами, функции перехвата сообщений).

Функция фильтра может находиться либо в приложении, устанавливающем фильтр, либо (что значительно лучше) в DLL-библиотеке. Если функция находится в приложении, или в DLL-библиотеке, загружаемой явным образом при помощи функции LoadLibrary, в качестве параметра lpfn следует использовать значение, полученное от функции MakeProcInstance. Если же для импортирования функций из DLL-библиотеки используется библиотека импорта (как в описанном ниже приложении WINHOOK), параметр lpfn может содержать непосредственный указатель на функцию фильтра.

Через параметр hInstance функции SetWindowsHookEx следует передать идентификатор модуля, в котором находится встраиваемая функция фильтра. Если функция фильтра определена внутри приложения, в качестве этого параметра необходимо использовать идентификатор текущей копии приложения, передаваемой через соответствующий параметр функции WinMain. Если же функция фильтра находится в DLL-библиотеке, данный параметр должен содержать идентификатор модуля библиотеки, передаваемый через параметр hInstance функции LibMain.

Последний параметр функции hTask должен содержать идентификатор задачи, для которой определяется функция фильтра. Если последний параметр указан как NULL, фильтр встраивается для всех задач, работающих в системе.

Если приложение встраивает фильтр для себя, оно должно определить идентификатор задачи, соответствующий собственной копии приложения. Это проще всего сделать, вызвав функцию GetCurrentTask :

HTASK WINAPI GetCurrentTask(void);

Можно определить идентификатор задачи исходя из идентификатора окна, созданного этой задачей. Для этого следует воспользоваться функцией GetWindowTask :

HTASK WINAPI GetWindowTask(HWND hwnd);

Эта функция возвращает идентификатор задачи, создавшей окно с идентификатором hwnd.

Функция SetWindowsHookEx возвращает 32-разрядный идентификатор функции фильтра, который следует сохранить для дальнейшего использования, или NULL при ошибке.

В приведенном ниже фрагменте кода, взятом из приложения WINHOOK, устанавливается фильтр для сообщений, поступающих во все приложения от клавиатуры:

hhook = SetWindowsHookEx(WH_KEYBOARD,
  (HOOKPROC)KbHookProc,
  hInst, NULL); 

Исходный текст функции фильтра приведен (с сильными сокращениями) ниже:

extern "C"
LRESULT CALLBACK KbHookProc(int code,
  WPARAM wParam, LPARAM lParam)
{
  ...
  ...
  ...
  // Вызываем следующий в цепочке перехватчик
  return CallNextHookEx(hhook, code, wParam, lParam);
}

После выполнения всех необходимых действий функция фильтра передает управление по цепочке другим фильтрам (что необязательно). Для этого вызывается функция CallNextHookEx :

LRESULT WINAPI CallNextHookEx(
  HHOOK hHook,
  int code,
  WPARAM wParam,
  LPARAM lParam);

Параметр hHook содержит идентификатор текущей функции фильтра.

Параметр code содержит код фильтра, который должен передаваться следующему фильтру в цепочке.

Параметры wParam и lParam содержат, соответственно, 16- и 32-битовый дополнительные параметры.

Параметры code, wParam и lParam функции CallNextHookEx полностью соответствуют параметрам функции фильтра, которая будет рассмотрена нами позже.

Отмена фильтра

Фильтр, установленный функцией SetWindowsHookEx, можно отменить или удалить при помощи функции UnhookWindowsHookEx :

BOOL WINAPI UnhookWindowsHookEx(HHOOK hHook);

В качестве единственного параметра этой функции следует передать идентификатор функции фильтра, полученный от функции SetWindowsHookEx.

Если отмена фильтра выполнена успешно, функция UnhookWindowsHookEx возвращает значение TRUE. В случае возникновения ошибки возвращается FALSE.

Функции фильтра

Функция фильтра должна иметь следующий прототип:

LRESULT CALLBACK HookProc(
  int code,
  WPARAM wParam,
  LPARAM lParam)

Имя функции фильтра может быть любым, так как при установке фильтра вы должны указать функции SetWindowsHookEx указатель на функцию фильтра.

Параметр code может определять действия, выполняемые функцией фильтра. В операционной системе Windows версии 3.0 этот параметр мог принимать отрицательные значения. В этом случае функция фильтра должна была передавать управление следующему в цепочке фильтру при помощи функции DefHookProc. Операционная система Windows версии 3.1 никогда не вызывает функцию фильтра с отрицательным значением параметра code.

Назначение параметров wParam и lParam зависит от типа фильтра, задаваемого при помощи параметра idHook функции SetWindowsHookEx. Мы не будем подробно описывать все возможные типы фильтров, так как это займет очень много времени. При необходимости вы сможете найти полное описание в документации, поставляющейся вместе с SDK. Рассмотрим в деталях только самые интересные, на наш взгляд, типы фильтров.

Фильтр WH_CALLWNDPROC

Приведем прототип функции фильтра типа WH_CALLWNDPROC (для функции можно использовать любое имя):

LRESULT CALLBACK CallWndProc(
  int code,       // код действия
  WPARAM wParam,  // флаг текущей задачи
  LPARAM lParam)  // адрес структуры с сообщением

Функция CallWndProc обязательно должна находиться DLL-библиотеке. Она вызывается операционной системой Windows после вызова функции SendMessage, но перед тем, как сообщение попадет в функцию окна, для которой оно предназначено. Фильтр может изменить любые параметры сообщения или его код.

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

Если сообщение послано текущей задачей, значение параметра wParam отлично от нуля, в противном случае оно равно NULL.

Параметр lParam содержит указатель на структуру, которая описывает перехваченное сообщение (эта структура на описана в файле windows.h):

struct _Msg
{
  LPARAM lParam;  // параметр lParam сообщения
  WPARAM wParam;  // параметр wParam сообщения
  UINT   uMsg;    // код сообщения
  HWND   hWnd;    // идентификатор окна, для которого
};                // предназначено сообщение

Функция фильтра должна всегда возвращать нулевое значение.

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

Фильтр WH_CBT

Большинство приложений, созданных фирмой Microsoft для своей операционной системы Windows, имеют встроенные обучающие системы, предназначенные для того, чтобы пользователь мог быстрее освоить работу с приложением. Например, текстовый процессор Microsoft Word for Windows версий 2.0 и 6.0 имеет очень удобную и легкую в использовании обучающую систему. Эта обучающая система не только рассказывает пользователю о том, как надо работать с текстовым процессором, но и, что очень важно, дает ему возможность попробовать выполнить те или иные действия самостоятельно. Когда пользователь пытается работать самостоятельно, все выглядит так, как будто он имеет дело с настоящим текстовым процессором, но при этом его действия ограничиваются обучающей системой.

Для облегчения создания подобных обучающих программ приложения могут установить фильтр WH_CBT, специально предназначенный для организации контроля за действиями пользователя со стороны обучающих программ. Мы не беремся утверждать, что обучающая программа для текстового процессора Microsoft Word for Windows построена с использованием этого фильтра, однако, вполне вероятно, что это так и есть.

Приведем прототип функции фильтра WH_CBT:

LRESULT CALLBACK CBTProc(               
  int code,       // код действия      
  WPARAM wParam,  // назначение зависит от кода действия
  LPARAM lParam); // назначение зависит от кода действия

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

Фильтр может разрешить или запретить выполнение перечисленных выше операций, возвращая соответствующее значение.

В зависимости от параметра code меняется назначение параметров wParam и lParam. Перечислим возможные значения для параметра code и кратко опишем назначение остальных параметров функции фильтра WH_CBT.

typedef struct tagCBTACTIVATESTRUCT { 
  BOOL fMouse;
  HWND hWndActive;
} CBTACTIVATESTRUCT;

typedef struct tagCREATESTRUCT
{
    void FAR* lpCreateParams;
    HINSTANCE hInstance;
    HMENU     hMenu;
    HWND      hwndParent;
    int       cy;
    int       cx;
    int       y;
    int       x;
    LONG      style;
    LPCSTR    lpszName;
    LPCSTR    lpszClass;
    DWORD     dwExStyle;
} CREATESTRUCT;

typedef struct tagMOUSEHOOKSTRUCT
{
  POINT pt;
  HWND  hwnd;
  UINT  wHitTestCode;
  DWORD dwExtraInfo;
} MOUSEHOOKSTRUCT;

Фильтр WH_DEBUG

Приведем прототип функции фильтра типа WH_DEBUG :

LRESULT CALLBACK DebugProc(
  int code,       // код действия
  WPARAM wParam,  // идентификатор задачи
  LPARAM lParam); // адрес структуры DEBUGHOOKINFO

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

Параметр wParam содержит идентификатор задачи, которая установила фильтр.

Параметр lParam содержит дальний указатель на структуру DEBUGHOOKINFO :

typedef struct tagDEBUGHOOKINFO
{
  HMODULE  hModuleHook;
  LPARAM   reserved;
  LPARAM   lParam;
  WPARAM   wParam;
  int      code;
} DEBUGHOOKINFO;

В этой структуре в поле hModuleHook находится идентификатор модуля, содержащего функцию фильтра, поля lParam, wParam, code содержат параметры, передаваемые функции фильтра. Поле reserved не используется.

Функция фильтра типа WH_DEBUG может предотвратить вызов другого фильтра, для чего она должна возвратить значение TRUE. Если она вернет FALSE, управление будет передано соответствующему фильтру.

Фильтр WH_GETMESSAGE

Фильтр WH_GETMESSAGE получает управление, когда функция GetMessage или PeekMessage возвращают выбранное из очереди сообщение. Функция фильтра должна находиться в DLL-библиотеке.

Приведем прототип функции фильтра типа WH_GETMESSAGE:

LRESULT CALLBACK GetMsgProc(
  int code,       // код действия
  WPARAM wParam,  // не определено
  LPARAM lParam); // адрес структуры MSG

Параметр lParam содержит указатель на структуру MSG , содержащую перехваченное сообщение:

typedef struct tagMSG
{
  HWND   hwnd;
  UINT   message;
  WPARAM wParam;
  LPARAM lParam;
  DWORD  time;
  POINT  pt;
} MSG;

Функция фильтра может изменить любой параметр сообщения и даже его код. В последнем случае произойдет замена одного сообщения на другое.

Возвращаемое функцией фильтра значение должно всегда равняться нулю.

Фильтр WH_HARDWARE

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

Приведем прототип функции фильтра типа WH_HARDWARE:

LRESULT CALLBACK HardwareProc(
  int code,       // код действия
  WPARAM wParam,  // не определено
  LPARAM lParam); // адрес структуры HARDWAREHOOKSTRUCT

Структура HARDWAREHOOKSTRUCT описана в файле windows.h:

typedef struct tagHARDWAREHOOKSTRUCT
{
   HWND    hWnd;
   UINT    wMessage;
   WPARAM  wParam;
   LPARAM  lParam;
} HARDWAREHOOKSTRUCT;

В этой структуре поле hWnd содержит идентификатор окна, которому предназначено сообщение, поле wMessage содержит код сообщения, поля wParam и lParam содержат дополнительную информацию, зависящую от кода сообщения.

Фильтр WH_JOURNALRECORD

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

Приведем прототип функции фильтра типа WH_JOURNALRECORD:

LRESULT CALLBACK JournalRecordProc(
  int code,       // код действия
  WPARAM wParam,  // содержит NULL
  LPARAM lParam); // адрес структуры EVENTMSG

Данный фильтр предназначен для записи перехваченных сообщений в память или файл. Он не может изменять или удалять сообщения из системной очереди.

Параметр code может принимать одно из трех значений:

Структура EVENTMSG описана в файле windows.h:

typedef struct tagEVENTMSG
{
  UINT   message;
  UINT   paramL;
  UINT   paramH;
  DWORD  time;
} EVENTMSG;

Фильтр WH_JOURNALPLAYBACK

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

Приведем прототип функции фильтра типа WH_JOURNALPLAYBACK:

LRESULT CALLBACK JournalPlaybackProc(
  int code,       // код действия
  WPARAM wParam,  // содержит NULL
  LPARAM lParam); // адрес структуры EVENTMSG

Перед возвратом управления функция фильтра WH_JOURNALPLAYBACK должна записать по адресу, переданному ей через параметр lParam, структуру данных, записанную ранее функцией фильтра WH_JOURNALRECORD.

Функция фильтра должна вернуть интервал времени ожидания (в машинных тиках) перед тем как Windows начнет обработку сообщения. Если вернуть нулевое значение, ожидание выполняться не будет.

Фильтр WH_KEYBOARD

Фильтр WH_KEYBOARD получает управление, когда функции GetMessage или PeekMessage возвращают сообщения WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP или WM_CHAR. Функция фильтра должна находиться в DLL-библиотеке.

Приведем прототип функции фильтра типа WH_KEYBOARD:

LRESULT CALLBACK KeyboardProc(
  int code,       // код действия
  WPARAM wParam,  // код виртуальной клавиши
  LPARAM lParam); // дополнительная информация

Параметр code может принимать значения HC_ACTION и HC_NOREMOVE. В первом случае перехваченное сообщение после обработки будет удалено из системной очереди сообщений, во втором - останется в этой очереди (т. к. оно было выбрано при помощи функции PeekMessage с параметром PM_NOREMOVE). Если сообщение останется в очереди, таблица состояния клавиатуры, которую можно получить при помощи функции GetKeyboardState, может не отражать состояние клавиатуры на момент выборки сообщения.

Параметры wParam и lParam содержат ту же самую информацию, что и соответствующие параметры клавиатурных сообщений WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP, WM_CHAR.

Параметр wParam содержит код виртуальной клавиши, соответствующей нажатой физической клавише. Именно этот параметр используется приложениями для идентификации нажатой клавиши.

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

При помощи этого фильтра приложение может удалить клавиатурное сообщение. Для удаления сообщения функция фильтра должна вернуть значение 1. Если же возвращенное значение будет равно 0, сообщение будет обработано системой.

Фильтр WH_MOUSE

Фильтр WH_MOUSE получает управление, когда функции GetMessage или PeekMessage возвращают сообщения мыши. Функция фильтра должна находиться в DLL-библиотеке.

Приведем прототип функции фильтра типа WH_MOUSE:

LRESULT CALLBACK MouseProc(
  int code,       // код действия
  WPARAM wParam,  // код сообщения
  LPARAM lParam); // указатель на структуру MOUSEHOOKSTRUCT

Так же, как и для предыдущего фильтра, параметр code может принимать значения HC_ACTION и HC_NOREMOVE.

Параметр wParam содержит код сообщения, поступившего от мыши.

Через параметр lParam передается указатель на структуру MOUSEHOOKSTRUCT :

typedef struct tagMOUSEHOOKSTRUCT
{
   POINT  pt;
   HWND   hwnd;
   UINT   wHitTestCode;
   DWORD  dwExtraInfo;
} MOUSEHOOKSTRUCT;

Эта структура содержит дополнительную информацию, имеющую отношение к сообщению.

Поле pt является структурой типа POINT, в которой находятся экранные x- и y-координаты курсора мыши. Поле hwnd содержит идентификатор окна, в функцию которого будет направлено сообщение. В поле wHitTestCode находится код тестирования, определяющий область окна, соответствующую расположению курсора мыши на момент генерации сообщения. Поле dwExtraInfo содержит дополнительную информацию, которую можно получить с помощью функции GetMessageExtraInfo :

LPARAM WINAPI GetMessageExtraInfo(void);

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

Фильтр WH_MSGFILTER

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

Приведем прототип функции фильтра типа WH_MSGFILTER:

LRESULT CALLBACK MessageProc(
  int code,       // код действия
  WPARAM wParam,  // не определено
  LPARAM lParam); // указатель на структуру MSG

Параметр code может принимать значения MSGF_DIALOGBOX (ввод в диалоговой панели), MSGF_SCROLLBAR (ввод в области полосы просмотра), MSGF_MENU (ввод в меню) или MSGF_NEXTWINDOW (пользователь активизирует следующее окно, нажимая комбинацию клавиш <Alt + Tab> или <Alt + Esc>).

Если фильтр обрабатывает сообщение, функция фильтра должна вернуть ненулевое значение, если нет - нулевое.

Фильтр WH_SYSMSGFILTER

Фильтр WH_SYSMSGFILTER получает управление, когда диалоговая панель или меню выбирает сообщение. Функции фильтра разрешается изменить или обработать перехваченное сообщение. Фильтр WH_SYSMSGFILTER может находиться только DLL-библиотеке. Назначение этого фильтра аналогично назначению фильтра WH_MSGFILTER, но он может быть установлен только для всей системы в целом.

Приведем прототип функции фильтра типа WH_SYSMSGFILTER:

LRESULT CALLBACK SysMsgProc(
  int code,       // код действия
  WPARAM wParam,  // не определено
  LPARAM lParam); // указатель на структуру MSG

Если фильтр обрабатывает сообщение, функция фильтра должна вернуть ненулевое значение, если нет - нулевое.

Приложение может установить одновременно фильтры WH_SYSMSGFILTER и WH_MSGFILTER, в этом случае вначале вызывается фильтр WH_SYSMSGFILTER, а затем - фильтр WH_MSGFILTER. Если же функция фильтра WH_SYSMSGFILTER возвращает ненулевое значение, фильтр WH_MSGFILTER не вызывается.

Фильтр WH_SHELL

Фильтр WH_SHELL предназначен для приложений-оболочек (shell application) и позволяет получать необходимые извещения от операционной системы Windows.

Приведем прототип функции фильтра типа WH_SHELL:

LRESULT CALLBACK ShellProc(
  int code,       // код действия
  WPARAM wParam,  // флаг текущей задачи
  LPARAM lParam); // не определено

Параметр code может принимать одно из следующих значений:

Функция фильтра должна вернуть нулевое значение.

3.7. Приложение WINHOOK

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

Для того чтобы Windows стала "понимать" русские символы, необходимо решить несколько задач.

Во-первых, клавиатура персонального компьютера IBM PC не предназначена для ввода символов кириллицы. В операционной системе MS-DOS эта проблема решалась с помощью резидентных программ, перехватывающих аппаратное прерывание от клавиатуры и заменяющих коды символов. Для операционной системы Microsoft Windows этот способ непригоден, так как для работы с клавиатурой используется специальный драйвер.

Во-вторых, необходимо обеспечить отображение символов кириллицы на экране монитора. В MS-DOS для отображения символов кириллицы в текстовом режиме можно было выполнить загрузку таблиц знакогенератора, расположенных в памяти видеоконтроллера. Операционная система Windows не использует текстовый режим, и, соответственно, не использует таблицы знакогенератора. Зато для нее предусмотрен механизм шрифтов различного типа - матричных, векторных и масштабируемых. Очевидно, что единственный способ отображения символов кириллицы в среде Windows - это подготовка версий шрифтов с кириллицей.

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

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

В этом разделе мы приведем исходные тексты приложения WINHOOK, которое решает первую из перечисленных выше задач, т. е. обеспечивает ввод с клавиатуры символов кириллицы. Приложение WINHOOK позволяет вам изменять раскладку клавиатуры с используемой по умолчанию на определенную в ресурсах приложения. Переключение раскладки выполняется при помощи левой или правой клавиши <Control>. Сразу после запуска приложения включается стандартная раскладка клавиатуры. Если вы нажмете на клавишу <Control> три раза, то услышите звуковой сигнал, после чего раскладка клавиатуры меняется на альтернативную и вы можете вводить символы кириллицы.

Приложение WINHOOK создает "непотопляемое" окно, которое располагается над поверхностью любого другого окна в Windows. Вы можете перемещать это окно мышью или изменять его размеры. В зависимости от используемой раскладки клавиатуры в окне отображается одно из двух слов: DEFAULT для стандартной раскладки и CYRILLIC для дополнительной (рис. 3.8).

Рис. 3.8. Главное окно приложения WINHOOK при использовании различных раскладок клавиатуры

Если для работы с кириллицей вы используете такие приложения, как CyrWin или ParaWin, перед запуском приложения WINHOOK их следует либо завершить, либо переключить раскладку клавиатуры на стандартную.

Для того чтобы завершить работу приложения WINHOOK, надо сделать его окно текущим, щелкнув по нему левой клавишей мыши, а затем нажать комбинацию клавиш <Alt + F4>.

Основной файл приложения WINHOOK приведен в листинге 3.9.

Листинг 3.9. Файл winhook/winhook.cpp

// ================================================
// Приложение WINHOOK
// Простейший руссификатор клавиатуры
// для Microsoft Windows
// Работает совместно с DLL-библиотекой kbhook.dll
// ================================================

#define STRICT
#include <windows.h>
#include <windowsx.h>
#include <dos.h>
#include <mem.h>

#include "kbhook.hpp"

// ----------------------------------------------------
// Прототипы функций
// ----------------------------------------------------

extern "C"
void WINAPI _export SetKbHook(HWND hwnd);

extern "C"
void WINAPI _export RemoveKbHook(void);

BOOL InitApp(HINSTANCE);
LRESULT CALLBACK _export WndProc(HWND, UINT, WPARAM, LPARAM);

// ----------------------------------------------------
// Глобальные переменные
// ----------------------------------------------------

char const szClassName[]   = "WINHOOKAppClass";
char const szWindowTitle[] = "WINHOOK Application";

TEXTMETRIC tm;
int cxChar, cyChar;
RECT rc;
static BOOL bCyrillic = FALSE;

// =====================================
// Функция WinMain
// =====================================
#pragma argsused

int PASCAL
WinMain(HINSTANCE hInstance,
        HINSTANCE hPrevInstance,
        LPSTR     lpszCmdLine,
        int       nCmdShow)
{
  MSG  msg;   // структура для работы с сообщениями
  HWND hwnd;  // идентификатор главного окна приложения

  // Можно запускать только одну копию приложения
  if(hPrevInstance)
    return 0;

  // Инициализация копии приложения
  if(!InitApp(hInstance))
      return FALSE;

  // Получаем координаты окна Desktop.
  // Это окно занимает всю поверхность экрана
  // и на нем расположены все остальные окна
  GetWindowRect(GetDesktopWindow(), &rc);

  // Создаем временное окно с толстой
  // рамкой для изменения размера, но без
  // заголовка и системного меню.
  // При создании окна указываем произвольные
  // размеры окна и произвольное расположение
  hwnd = CreateWindow(
    szClassName, szWindowTitle, 
    WS_POPUPWINDOW | WS_THICKFRAME,
    100, 100,
    100, 100,
    0, 0, hInstance, NULL); 

  if(!hwnd)
    return FALSE;

  // Передвигаем окно в правый нижний
  // угол экрана и делаем его самым
  // верхним, т. е. это окно будет
  // всегда находиться над другими окнами
  SetWindowPos(hwnd, HWND_TOPMOST,
    rc.right  - cxChar * 15,
    rc.bottom - cyChar * 3,
    cxChar * 10, cyChar * 2, 0);

  // Отображаем окно в новом месте
  ShowWindow(hwnd, nCmdShow);
  UpdateWindow(hwnd);

  // Запускаем цикл обработки сообщений
  while(GetMessage(&msg, 0, 0, 0))
  {
    DispatchMessage(&msg);
  }
  return msg.wParam;
}

// =====================================
// Функция InitApp
// =====================================

BOOL
InitApp(HINSTANCE hInstance)
{
  ATOM aWndClass; // атом для кода возврата
  WNDCLASS wc;    // структура для регистрации
                  // класса окна

  memset(&wc, 0, sizeof(wc));
  wc.style         = CS_HREDRAW | CS_VREDRAW;
  wc.lpfnWndProc   = (WNDPROC) WndProc;
  wc.cbClsExtra    = 0;
  wc.cbWndExtra    = 0;
  wc.hInstance     = hInstance;
  wc.hIcon   = LoadIcon(NULL, IDI_APPLICATION);
  wc.hCursor = LoadCursor(NULL, IDC_ARROW);
  wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
  wc.lpszMenuName  = (LPSTR)NULL;
  wc.lpszClassName = (LPSTR)szClassName;

  aWndClass = RegisterClass(&wc);
  return (aWndClass != 0);
}

// =====================================
// Функция WndProc
// =====================================

LRESULT CALLBACK _export
WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
  HDC        hdc;
  PAINTSTRUCT ps;

  switch (msg)
  {
    case WM_CREATE:
    {
      // Устанавливаем перехватчики
      SetKbHook(hwnd);

      // Получаем контекст отображения
      hdc = GetDC(hwnd);

      // Выбираем шрифт с фиксированной шириной букв
      SelectObject(hdc, GetStockObject(SYSTEM_FIXED_FONT));

      // Заполняем структуру информацией
      // о метрике шрифта, выбранного в
      // контекст отображения
      GetTextMetrics(hdc, &tm);

      // Запоминаем значение ширины для
      // самого широкого символа
      cxChar = tm.tmMaxCharWidth;

      // Запоминаем значение высоты букв с
      // учетом межстрочного интервала
      cyChar = tm.tmHeight + tm.tmExternalLeading;

      ReleaseDC(hwnd, hdc);
      return 0;
    }

    // Для обеспечения возможности перемещения
    // окна, не имеющего заголовка, встраиваем
    // свой обработчик сообщения WM_NCHITTEST
    case WM_NCHITTEST:
    {
      long lRetVal;

      // Вызываем функцию DefWindowProc и проверяем
      // возвращаемое ей значение
      lRetVal = DefWindowProc(hwnd, msg, wParam, lParam);

      // Если курсор мыши находится на одном из
      // элементов толстой рамки, предназначенной
      // для изменения размера окна, возвращаем
      // неизмененное значение, полученное от
      // функции DefWindowProc
      if(lRetVal == HTLEFT        ||
         lRetVal == HTRIGHT       ||
         lRetVal == HTTOP         ||
         lRetVal == HTBOTTOM      ||
         lRetVal == HTBOTTOMRIGHT ||
         lRetVal == HTTOPRIGHT    ||
         lRetVal == HTTOPLEFT     ||
         lRetVal == HTBOTTOMLEFT)
      {
        return lRetVal;
      }

      // В противном случае возвращаем значение
      // HTCAPTION, которое соответствует
      // заголовку окна.
      else
      {
        return HTCAPTION;
      }
    }

    case WM_DESTROY:
    {
      // Перед завершением работы приложения
      // удаляем перехватчики
      RemoveKbHook();

      PostQuitMessage(0);
      return 0;
    }

    // Это сообщение приходит от DLL-библиотеки
    // при переключении раскладки клавиатуры
    case WM_KBHOOK:
    {
      // Получаем флаг раскладки
      bCyrillic = (BOOL)wParam;

      // Выдаем звуковой сигнал
      MessageBeep(0);

      // Перерисовываем окно приложения
      InvalidateRect(hwnd, NULL, FALSE);
      return 0;
    }

    case WM_PAINT:
    {
      BYTE   szBuf[10];
      RECT    rc;

      // Получаем контекст отображения
      hdc = BeginPaint(hwnd, &ps);

      // Выбираем шрифт с фиксированной шириной букв
      SelectObject(hdc, GetStockObject(SYSTEM_FIXED_FONT));

      // Получаем координаты и размер окна
      GetClientRect(hwnd, &rc);

      // В зависимости от состояния флага раскладки
      // клавиатуры выбираем надпись для
      // отображения в окне
      if(bCyrillic)
        lstrcpy(szBuf, (LPCSTR)"CYRILLIC");
      else
        lstrcpy(szBuf, (LPCSTR)"DEFAULT ");

      // Выводим надпись в центре окна
      DrawText(hdc, (LPSTR)szBuf, 8, &rc,
        DT_CENTER | DT_VCENTER | DT_NOCLIP | DT_SINGLELINE);

      EndPaint(hwnd, &ps);
    }
  }
  return DefWindowProc(hwnd, msg, wParam, lParam);
}

После запуска приложения функция WinMain определяет размеры окна DeskTop, которые равны размеру экрана, и создает главное окно приложения в виде временного окна с толстой рамкой для изменения размера без заголовка и системного меню (такое окно имеет стиль WS_POPUPWINDOW | WS_THICKFRAME).

Для того чтобы сделать окно "непотопляемым", а заодно и изменить его размеры, мы вызываем функцию SetWindowPos , передав ей в качестве второго параметра константу HWND_TOPMOST:

SetWindowPos(hwnd, HWND_TOPMOST,
   rc.right  - cxChar * 15,
   rc.bottom - cyChar * 3,
   cxChar * 10, cyChar * 2, 0);

Функция SetWindowPos позволяет изменить размеры и расположение окна относительно экрана и относительно других окон:

BOOL WINAPI SetWindowPos(
  HWND hwnd,            // идентификатор окна
  HWND hwndInsertAfter, // расположение окна
  int x,                // горизонтальное положение 
  int y,                // вертикальное положение
  int cx,               // ширина
  int cy,               // высота
  UINT fuFlags);        // флаги расположения окна

Для параметра hwndInsertAfter, определяющего расположение окна относительно других окон, можно использовать следующие значения:

Параметры x, y, cx и cy определяют, соответственно, горизонтальное и вертикальное расположение окна, его ширину и высоту.

Параметр fuFlags может принимать следующие значения:

После перемещения и изменения расположения главного окна функция WinMain приложения WINHOOK отображает окно и запускает цикл обработки сообщений.

Функция главного окна приложения во время обработки сообщения WM_CREATE вызывает функцию SetKbHook, которая определена в созданной нами для этого приложения DLL-библиотеке kbhook.dll (исходные тексты этой библиотеки будут приведены ниже). Функция SetKbHook устанавливает два фильтра - типа WH_KEYBOARD и WH_GETMESSAGE. В качестве параметра этой функции передается идентификатор главного окна приложения WINHOOK. Когда пользователь переключает раскладку клавиатуры, DLL-библиотека, пользуясь этим идентификатором, пришлет в функцию окна приложения WINHOOK сообщение с кодом WM_KBHOOK.

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

В функции главного окна предусмотрен обработчик сообщения WM_NCHITTEST, позволяющий перемещать окно, не имеющее заголовка. Мы уже использовали аналогичный прием в приложении TMCLOCK, описанном в 11 томе "Библиотеки системного программиста".

Перед завершением работы приложение WINHOOK удаляет установленные ранее фильтры, для чего при обработке сообщения WM_DESTROY вызывается функция RemoveKbHook, определенная в DLL-библиотеке kbhook.dll.

Обработчик сообщения WM_KBHOOK, определенного в нашем приложении и в DLL-библиотеке, определяет номер используемой раскладки клавиатуры через параметр wParam. Полученное значение записывается в переменную флагов раскладки bCyrillic. Если этот флаг сброшен, используется стандартная раскладка клавиатуры, если установлен - дополнительная с символами кириллицы.

После определения раскладки обработчик сообщения WM_KBHOOK выдает звуковой сигнал и перерисовывает главное окно приложения, вызывая функцию InvalidateRect.

Перерисовку окна выполняет обработчик сообщения WM_PAINT. С помощью функции DrawText он пишет название раскладки клавиатуры (DEFAULT или CYRILLIC) в центре главного окна приложения.

Сообщение WM_KBHOOK определено в include-файле winhook.hpp (листинг 3.10).

Листинг 3.10. Файл winhook/winhook.hpp

#define WM_KBHOOK (WM_USER + 1000)

Код этого сообщения получается при помощи сложения константы WM_USER и числа 1000 (вы можете выбрать другое число в диапазоне от 0 до 0x7fff).

Константа WM_USER специально предназначена для определения приложениями своих собственных кодов сообщений. Если приложение определит свое собственное сообщение и его код будет находиться в пределах от WM_USER до WM_USER + 0x7fff, код такого сообщения не будет конфликтовать с кодами сообщений операционной системы Windows.

Файл определения модуля приложения WINHOOK приведен в листинге 3.11.

Листинг 3.11. Файл winhook/winhook.def

; =============================
; Файл определения модуля
; =============================
NAME        WINHOOK
DESCRIPTION 'Приложение WINHOOK, (C) 1994, Frolov A.V.'
EXETYPE     windows
STUB        'winstub.exe'
STACKSIZE   8120
HEAPSIZE    1024
CODE        preload moveable discardable
DATA        preload moveable multiple

Теперь займемся DLL-библиотекой kbhook.dll, предназначенной для совместной работы с приложением WINHOOK. Исходный текст этой библиотеки представлен в листинге 3.12.

Листинг 3.12. Файл winhook/kbhook.cpp

// ================================================
// DLL-библиотека kbhook.dll
// Устанавливает перехватчики на сообщения,
// поступающие от клавиатуры и на системную
// очередь сообщений.
// Если нажать подряд 3 раза клавишу <Control>,
// изменится раскладка клавиатуры
// ================================================

#define  STRICT
#include <windows.h>
#include "kbhook.hpp"

// -----------------------------------------------
// Глобальные переменные
// -----------------------------------------------

// Идентификатор модуля DLL-библиотеки
static HINSTANCE hInst;

// Идентификатор окна приложения, установившего
// перехватчики
static HWND hwndClient;

// Идентификаторы перехватчиков
static HHOOK hhook = 0;
static HHOOK hhookMsg = 0;

// Флаг переключения на русскую клавиатуру
static BOOL bCyrillic = FALSE;

// Флаг установки перехватчиков
static BOOL bHooked = FALSE;

// Счетчик 
static int nHotKeyCount = 0;

// Массив для записи состояния клавиатуры
BYTE aKeyStates[256];

// Указатели на таблицы перекодировки,
// которые будут загружены из ресурсов
static char far * lpXlatTable;
static char far * lpXlatTableCaps;

// Положение ресурсов в файле
static HRSRC   hResource;
static HRSRC   hResourceCaps;

// Идентификаторы таблиц перекодировки
static HGLOBAL hXlatTable;
static HGLOBAL hXlatTableCaps;

// -----------------------------------------------
// Прототипы функций
// -----------------------------------------------

extern "C"
LRESULT CALLBACK KbHookProc(int code,
  WPARAM wParam, LPARAM lParam);

extern "C"
LRESULT CALLBACK MsgHookProc(int code,
  WPARAM wParam, LPARAM lParam);

// ========================================================
// Функция LibMain
// Получает управление только один раз при
// загрузке DLL-библиотеки в память
// ========================================================

#pragma argsused
int CALLBACK
LibMain(HINSTANCE hInstance,
                  WORD wDataSegment,
                  WORD wHeapSize,
                  LPSTR lpszCmdLine)
{
  // После инициализации локальной области данных
  // функция LibEntry фиксирует сегмент данных.
  // Его необходимо расфиксировать.
  if(wHeapSize != 0)
    // Расфиксируем сегмент данных
    UnlockData(0);

  // Запоминаем идентификатор модуля DLL-библиотеки
  hInst = hInstance;

  // Определяем расположение ресурсов
  hResource   = FindResource(hInstance, "XlatTable", "XLAT");
  hResourceCaps = 
    FindResource(hInstance, "XlatTableCaps", "XLAT");

  // Получаем идентификаторы ресурсов
  hXlatTable  = LoadResource(hInstance, hResource);
  hXlatTableCaps  = LoadResource(hInstance, hResourceCaps);

  // Фиксируем ресурсы в памяти, получая их адрес
  lpXlatTable = (char far *)LockResource(hXlatTable);
  lpXlatTableCaps = (char far *)LockResource(hXlatTableCaps);

  // Если адрес равен NULL, при загрузке или
  // фиксации одного из ресурсов произошла ошибка
  if(lpXlatTable == NULL || lpXlatTableCaps == NULL)
  {
    return(0);
  }

  // Выключаем клавишу <Caps Lock>. Для этого
  // получаем и записываем в массив  aKeyStates состояние
  // клавиатуры, затем изменяем состояние нужной нам
  // клавиши, используя ее виртуальный код как индекс
  GetKeyboardState(aKeyStates);
  aKeyStates[VK_CAPITAL] = 0;
  SetKeyboardState(aKeyStates);

  // Возвращаем 1. Это означает, что инициализация
  // DLL-библиотеки выполнена успешно
  return 1;
}

// ========================================================
// Функция WEP
// Получает управление только один раз при
// удалении DLL-библиотеки из памяти
// ========================================================

#pragma argsused
int CALLBACK
WEP(int bSystemExit)
{
  // Расфиксируем и освобождаем ресурсы
  UnlockResource(hXlatTable);
  FreeResource(hXlatTable);
  UnlockResource(hXlatTableCaps);
  FreeResource(hXlatTableCaps);

  return 1;
}

// ========================================================
// Функция SetKbHook
// Устанавливает системные перехватчики на сообщения,
// поступающие от клавиатуры, и на системную
// очередь сообщений
// ========================================================

extern "C"
void WINAPI _export SetKbHook(HWND hwnd)
{
  // Устанавливаем перехватчики только
  // в том случае, если они не были
  // установлены ранее 
  if(!bHooked)
  {
    // Установка перехватчика на сообщения,
    // поступающие от клавиатуры
    hhook = SetWindowsHookEx(WH_KEYBOARD,
      (HOOKPROC)KbHookProc,
      hInst, NULL); 

    // Установка перехватчика на системную
    // очередь сообщений
    hhookMsg = SetWindowsHookEx(WH_GETMESSAGE,
      (HOOKPROC)MsgHookProc,
      hInst, NULL);

    // Включаем флаг установки перехватчиков
    bHooked = TRUE;

    // Сохраняем идентификатор окна приложения,
    // установившего перехватчики
    hwndClient = hwnd;
  }
}

// ========================================================
// Функция RemoveKbHook
// Удаляет системные перехватчики
// ========================================================

extern "C"
void WINAPI _export RemoveKbHook(void)
{
  // Если перехватчики были установлены,
  // удаляем их
  if(bHooked)
  {
    UnhookWindowsHookEx(hhookMsg);
    UnhookWindowsHookEx(hhook);
  }
}

// ========================================================
// Функция KbHookProc
// Перехватчик сообщений от клавиатуры
// ========================================================

extern "C"
LRESULT CALLBACK KbHookProc(int code,
  WPARAM wParam, LPARAM lParam)
{
  // Проверка флага обработки сообщений. Если содержимое
  // параметра code меньше нуля, передаем сообщение
  // функции CallNextHookEx без изменений
  if(code < 0)
  {
    CallNextHookEx(hhook, code, wParam, lParam);
    return 0;
  }

  // Если пришло сообщение от клавиши <Control>,
  // проверяем, была ли эта клавиша нажата
  // три раза подряд
  if(wParam  == VK_CONTROL)
  { 
    if(!(HIWORD(lParam) & 0x8000))
    {
      nHotKeyCount++;

      // Если клавиша <Control> была нажата три
      // раза подряд, инвертируем флаг bCyrillic и посылаем
      // сообщение приложению, использующему
      // данную DLL-библиотеку
      if(nHotKeyCount == 3)
      {
        nHotKeyCount = 0;
        bCyrillic = ~bCyrillic;

        // Посылаем сообщение приложению, установившему
        // перехватчики. В качестве параметра wParam
        // сообщения передаем значение флага bCyrillic
        PostMessage(hwndClient, WM_KBHOOK,
          (WPARAM)bCyrillic, 0L);
      }
    }
  }

  // Если после клавиши <Control> была нажата любая
  // другая клавиша, сбрасываем счетчик
  else
  {
    nHotKeyCount = 0;
  }

  // Вызываем следующий в цепочке перехватчик
  return CallNextHookEx(hhook, code, wParam, lParam);
}

// ========================================================
// Функция MsgHookProc
// Перехватчик для системной очереди сообщений
// ========================================================

extern "C"
LRESULT CALLBACK MsgHookProc(int code,
  WPARAM wParam, LPARAM lParam)
{
  LPMSG lpmsg;
  WPARAM wMsgParam;

  // Проверка флага обработки сообщений. Если содержимое
  // параметра code меньше нуля, передаем сообщение
  // функции CallNextHookEx без изменений
  if(code < 0)
  {
    CallNextHookEx(hhook, code, wParam, lParam);
    return 0;
  }

  // Получаем указатель на структуру MSG,
  // в которой находится перехваченное сообщение
  lpmsg = (LPMSG)lParam;

  // Запоминаем виртуальный код клавиши
  wMsgParam = lpmsg->wParam;

  // Сбрасываем флаг замены сообщения
  // WM_KEYDOWN на сообщение WM_CHAR
  BOOL bChange = FALSE;

  // Если перехвачено сообщение WM_KEYDOWN,
  // проверяем код виртуальной клавиши и при
  // необходимости выполняем замену сообщения
  if(lpmsg->message == WM_KEYDOWN)
  {
    // Замена выполняется только в режиме
    // русской клавиатуры
    if(bCyrillic)
    {
      // Если нажата клавиша, соответствующая
      // русской букве, включаем флаг bChange
      switch(wMsgParam)
      {
        // Проверяем "особые" буквы
        case 0xdb: // "Х"
        case 0xdd: // "Ъ"
        case 0xba: // "Ж"
        case 0xde: // "Э"
        case 0xbc: // "Б"
        case 0xbe: // "Ю"
        case 0xbf: // "Ў"
        {
          bChange = TRUE;
          break;
        }

        // Проверяем остальные буквы
        default:
        {
          if((lpmsg->wParam <= 0x5d && lpmsg->wParam > 0x2f))
            bChange = TRUE;
        }
      }

      // Если нажата клавиша, соответствующая русской
      // букве, выполняем замену сообщения WM_KEYDOWN на
      // сообщение WM_CHAR
      if(bChange)
      {
        // Делаем замену кода сообщения
        lpmsg->message = WM_CHAR;

        // Необходимо учитывать состояние клавиш
        // <Caps Lock> и <Shift>
        if(GetKeyState(VK_CAPITAL) & 0x1)
        {
          if(GetKeyState(VK_SHIFT) & 0x8000)
          {
            // Перекодировка по таблице строчных букв
            lpmsg->wParam =
              lpXlatTable[(lpmsg->wParam) & 0xff];
          }
          else
          {
            // Перекодировка по таблице прописных букв
            lpmsg->wParam =
              lpXlatTableCaps[(lpmsg->wParam) & 0xff];
          }
        }
        else
        {
          if(GetKeyState(VK_SHIFT) & 0x8000)
          {
            // Перекодировка по таблице прописных букв
            lpmsg->wParam = 
              lpXlatTableCaps[(lpmsg->wParam) & 0xff];
          }
          else
          {
            // Перекодировка по таблице строчных букв
            lpmsg->wParam = 
              lpXlatTable[(lpmsg->wParam) & 0xff];
          }
        }

        // Сбрасываем флаг замены
        bChange = FALSE;
      }
    }
  }

  // Передаем управление следующему в цепочке
  // перехватчику сообщений
  CallNextHookEx(hhook, code, wParam, lParam);

  return 0;
}

Функция LibMain, выполняющая инициализацию DLL-библиотеки, после инициализации сегмента данных, запоминает идентификатор модуля DLL-библиотеки, переданный ей через параметр hInstance, в глобальной переменной hinst.

Затем эта функция находит, загружает в память и фиксирует две таблицы, необходимые для использования дополнительной раскладки клавиатуры. Первая таблица загружается из ресурса "XlatTable". Она содержит таблицу перекодировки кодов виртуальных клавиш в ANSI-коды русских строчных букв. Вторая таблица загружается из ресурса "XlatTableCaps" и содержит таблицу перекодировки кодов виртуальных клавиш в ANSI-коды русских прописных букв.

После загрузки и фиксирования адреса таблиц записываются в глобальные переменные с именами lpXlatTable и lpXlatTableCaps.

Так как перекодировка кодов виртуальных клавиш в ANSI-коды должна выполняться с учетом состояния клавиши <Caps Lock>, для упрощения перекодировки функция LibMain устанавливает эту клавишу в выключенное состояние, пользуясь функциями GetKeyboardState и SetKeyboardState :

GetKeyboardState(aKeyStates);
aKeyStates[VK_CAPITAL] = 0;
SetKeyboardState(aKeyStates);

Указанные функции, а также использованный способ изменения состояния клавиш был описан в 11 томе "Библиотеки системного программиста".

Функция WEP выполняет расфиксирование и освобождение ресурсов, вызывая функции UnlockResource и FreeResource.

Для установки фильтров в нашей DLL-библиотеки определена функция SetKbHook:

extern "C"
void WINAPI _export SetKbHook(HWND hwnd)
{
  if(!bHooked)
  {
    hhook = SetWindowsHookEx(WH_KEYBOARD,
      (HOOKPROC)KbHookProc,
      hInst, NULL); 
    hhookMsg = SetWindowsHookEx(WH_GETMESSAGE,
      (HOOKPROC)MsgHookProc,
      hInst, NULL);
    bHooked = TRUE;
    hwndClient = hwnd;
  }

При определении этой функции мы использовали ключевые слова extern "C", в результате чего транслятор C++ не выполняет преобразование имени функции в соответствии с типом ее параметров и типом возвращаемого значения.

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

Функция SetKbHook устанавливает два фильтра - типа WH_KEYBOARD и типа WH_GETMESSAGE. Оба фильтра встраиваются для всей системы в целом, так как последний параметр функции SetWindowsHookEx указан как NULL.

После встраивания фильтров устанавливается флаг bHooked, в глобальную переменную hwndClient записывается идентификатор окна, переданного функции SetKbHook в качестве параметра. Приложение WINHOOK передает идентификатор своего главного окна, пользуясь которым фильтр, расположенный в DLL-библиотеке, будет посылать приложению WINHOOK сообщение WM_KBHOOK.

Для удаления фильтров в DLL-библиотеке определена функция RemoveKbHook:

extern "C"
void WINAPI _export RemoveKbHook(void)
{
  if(bHooked)
  {
    UnhookWindowsHookEx(hhookMsg);
    UnhookWindowsHookEx(hhook);
  }
}

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

Функция фильтра типа WH_KEYBOARD пропускает через себя все клавиатурные сообщения, определяя момент, когда пользователь нажмет подряд три раза клавишу <Control>.

Как только это произошло, функция фильтра инвертирует флаг bCyrillic и посылает приложению WINHOOK сообщение WM_KBHOOK. В качестве параметра wParam посылаемого сообщения используется значение флага bCyrillic, что позволяет определить приложению номер используемой раскладки клавиатуры:

PostMessage(hwndClient, WM_KBHOOK, (WPARAM)bCyrillic, 0L);

Фильтр типа WH_MSGFILTER расположен в функции MsgHookProc.

Если перехвачено сообщение WM_KEYDOWN, фильтр проверяет номер используемой раскладки клавиатуры. Если используется стандартная раскладка клавиатуры, сообщение "пропускается" через фильтр без изменений. Для дополнительной раскладки клавиатуры выполняется проверка кода виртуальной клавиши.

Если этот код соответствует клавишам русских букв или цифр в верхнем ряду клавиатуры, фильтр преобразует сообщение WM_KEYDOWN в сообщение WM_CHAR, пользуясь таблицами перекодировок, загруженным из ресурсов DLL-библиотеки. При этом учитывается состояние клавиш <Shift> и <Caps Lock>. Для определения состояния переключающих клавиш мы использовали функцию GetKeyState.

Таблицы перекодировки для прописных и строчных букв описаны в файле ресурсов DLL-библиотеки (листинг 3.13).

Листинг 3.13. Файл winhook/kbhook.rc

/* Таблица перекодировки */

XlatTableCaps XLAT 
BEGIN
'00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F'
'10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F'
'20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F'
'25 21 2D 2F 22 3A 2C 2E AD 3F 3A 3B 3C 3D 3E 3F'
'40 D4 C8 D1 C2 D3 C0 CF D0 D8 CE CB C4 DC D2 D9'
'C7 C9 CA DB C5 C3 CC D6 D7 CD DF 5B 5C 5D 5E 5F'
'60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F'
'70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F'
'80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F'
'90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F'
'A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF'
'B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 C6 BB C1 BD DE A1'
'C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF'
'D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA D5 DC DA DD DF'
'E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF'
'F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF'

END

XlatTable XLAT
BEGIN
'00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F'
'10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F'
'20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F'
'30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F'
'40 F4 E8 F1 E2 F3 E0 EF F0 F8 EE EB E4 FC F2 F9'
'E7 E9 EA FB E5 E3 EC F6 F7 ED FF 5B 5C 5D 5E 5F'
'60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F'
'70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F'
'80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F'
'90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F'
'A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF'
'B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 E6 BB E1 BD FE BF'
'C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF'
'D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA F5 DC FA FD DF'
'E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF'
'F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF'

END

Файл определения модуля DLL-библиотеки приведен в листинге 3.14.

Листинг 3.14. Файл winhook/kbhook.def

; =============================
; Файл определения модуля
; =============================
LIBRARY        KBHOOK
DESCRIPTION    'DLL-библиотека KBHOOK, (C) 1994, Frolov A.V.'
EXETYPE        windows
CODE           preload fixed
DATA           preload moveable single
HEAPSIZE       1024
EXPORTS
  SetKbHook    @10
  RemoveKbHook @11
  KbHookProc   @12
  MsgHookProc  @13

С помощью этого файла экспортируются функции SetKbHook и RemoveKbHook, предназначенные, соответственно, для установки и удаления фильтров, а также функции фильтров KbHookProc и MsgHookProc.