Что такое системная библиотека

• Что такое системная библиотека
• Как создать библиотеку
• Как установить библиотеку

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

Понятие системная библиотека применима как к отдельным программам, так и к операционным системам в целом, причем это касается семейств и Windows, и UNIX, и Mac.

Определение «библиотека» впервые появилось в 1951 году в книге М. Уилкса , Д. Уиллера и С. Гилла «Составление программ для электронных счётных машин»

По принципу действия системные библиотеки делятся на динамические и статические.

Динамические библиотеки

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

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

Файлы динамических библиотек в OC Windows имеют расширение .dll (Dynamic Link Library) и хранятся в каталоге system32. Аналогичные компоненты в UNIX подобных системах называются общие объекты (shared objects) и имеют расширение .so, в Mac OS — .dlyb.

Морис Уилкс с соавторами дал следующее определение библиотеке — короткая, заранее заготовленная программа для отдельных, часто встречающихся (стандартных) вычислительных операций.

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

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

Статические библиотеки

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

Как правило в Windows файлы таких библиотек имеют расширение .lib, в UNIX-подобных системах — .a.

Работа с большинством компилируемых языков, например, C, C++, Pascal, невозможна без статических библиотек.

Системные библиотеки windows имеют расширение

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

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

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

Вспомним старые добрые времена, когда операционная система 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-библиотеками.

Формат 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-библиотека пользуются одними и теми же функциями стандартной библиотеки компилятора в варианте статической компоновки.

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

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

Функция LibEntry

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

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

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

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

Регистры	Описание
DS	Селектор, указывающий на сегмент данных DLL-библиотеки. Отметим, что хотя сразу после загрузки DLL-библиотека имеет собственный сегмент данных, в нем не определена область локальных данных. Для определения области локальных данных функция LibEntry должна вызвать функцию LocalInit
DI	Идентификатор DLL-библиотеки, присвоенный ей операционной системой Windows после загрузки. По своему назначению аналогичен идентификатору приложения hInstance, передаваемому обычному приложению через соответствующий параметр функции WinMain. Идентификатор DLL-библиотеки используется функциями библиотеки при создании таких, например, объектов, как окна (если окно создается функцией, расположенной в DLL-библиотеке, при его создании следует использовать не идентификатор приложения hInstance, вызвавшего функцию, а идентификатор DLL-библиотеки)
CX	Требуемый размер локальной области данных, указанный в операторе HEAPSIZE файла определения модуля DLL-библиотеки. При вызове функции инициализации локальной области памяти LocalInit в качестве значения параметра uStartAddr следует использовать нуль, а в качестве значения параметра uEndAddr — содержимое регистра CX
ES:SI	Дальний указатель на строку параметров, которая может быть указана при явной загрузке DLL-библиотеки (позже мы рассмотрим различные способы загрузки DLL-библиотеки). Обычно этот параметр не используется

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

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

Функция LibMain

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

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

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

Параметр 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:

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

Функция WEP

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

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

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

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

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

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

В операционной системе 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 перечислены имена нескольких экспортируемых функций. Около некоторых имен после символа «@» указаны порядковые номера соответствующих функций в 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-библиотек:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код ошибки	Описание
0	Мало памяти, неправильный формат загружаемого файла
2	Файл не найден
3	Путь к файлу не существует
5	Была предпринята попытка динамически загрузить приложение или произошла ошибка при совместном использовании файлов. Также возможно, что была предпринята попытка доступа к файлу в сети пользователем, не имеющим на это достаточных прав
6	Данная библиотека требует отдельный сегмент данных для каждой задачи
8	Мало памяти для запуска приложения
10	Неправильная версия операционной системы Windows
11	Неправильный формат загрузочного файла приложения Windows
12	Данное приложение разработано для операционной системы, отличной от Microsoft Windows
13	Данное приложение разработано для MS-DOS версии 4.0
14	Неизвестный тип исполняемого файла
15	Была предпринята попытка загрузить приложение, разработанное для реального режима работы процессора в среде ранних версий операционной системы Windows
16	Была предпринята попытка загрузить вторую копию исполняемого файла, содержащего сегменты данных, отмеченные как multiple, но не защищенные от записи
19	Попытка загрузки компрессованного выполнимого файла
20	Файл, содержащий DLL-библиотеку, имеет неправильный формат
21	Данное приложение работает только в среде 32-битового расширения Windows

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Значение	Описание
SEM_FAILCRITICALERRORS	Операционная система Windows не выводит на экран сообщение обработчика критических ошибок, возвращая приложению соответствующий код ошибки
SEM_NOGPFAULTERRORBOX	На экран не выводится сообщение об ошибке защиты памяти. Этот флаг может использоваться только при отладке приложений, если они имеют собственный обработчик такой ошибки
SEM_NOOPENFILEERRORBOX	Если Windows не может открыть файл, на экран не выводится диалоговая панель с сообщением об ошибке

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

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

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

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

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

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

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

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

И, наконец, оператор 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) следующую команду:

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

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

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

Обратите внимание, что в заголовке присутствует информация об адресе точки входа (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)).

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

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

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

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

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

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

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

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

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

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

Функция 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

Во-первых, в нем нет оператора 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Константа	Назначение фильтра
WH_CALLWNDPROC	Для функции окна. Используется в Windows версии 3.0 и 3.1. Можно устанавливать для отдельной задачи или для всей системы
WH_CBT	Для обучающих программ. Можно устанавливать для отдельной задачи или для всей системы
WH_DEBUG	Для отладкиИспользуется в Windows версии 3.1. Можно устанавливать для отдельной задачи или для всей системы
WH_GETMESSAGE	Фильтр сообщений. Получает управление после выборки сообщения функцией GetMessageИспользуется в Windows версии 3.0 и 3.1. Можно устанавливать для отдельной задачи или для всей системы
WH_HARDWARE	Фильтр для сообщений, поступающих от нестандартного аппаратного обеспечения, такого как система перьевого ввода. Используется в Windows версии 3.1. Можно устанавливать для отдельной задачи или для всей системы
WH_JOURNALPLAYBACK	Фильтр для «проигрывания» событийИспользуется в Windows версии 3.0 и 3.1. Можно устанавливать только для всей системы
WH_JOURNALRECORD	Фильтр для записи событийИспользуется в Windows версии 3.0 и 3.1. Можно устанавливать только для всей системы
WH_KEYBOARD	Фильтр сообщений, поступающих от клавиатуры. Используется в Windows версии 3.1. Можно устанавливать для отдельной задачи или для всей системы
WH_MOUSE	Фильтр сообщений, поступающих от мыши. Используется в Windows версии 3.1. Можно устанавливать для отдельной задачи или для всей системы
WH_MSGFILTER	Фильтр сообщений, который получает управление после выборки, но перед обработкой сообщений, поступающих от диалоговых панелей или меню. Используется в Windows версии 3.0 и 3.1. Можно устанавливать для отдельной задачи или для всей системы
WH_SHELL	Фильтр для получения различных извещений от операционной системы Windows. Используется в Windows версии 3.1. Можно устанавливать для отдельной задачи или для всей системы
WH_SYSMSGFILTER	Фильтр вызывается операционной системой после того, как диалоговая панель или меню получат сообщение, но перед обработкой этого сообщения. Данный фильтр может обрабатывать сообщения для любых запущенных приложений Windows. Используется в Windows версии 3.0 и 3.1. Можно устанавливать только для всей системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фильтр WH_CALLWNDPROC

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

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

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

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

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

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

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

Фильтр WH_CBT

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

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

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

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

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

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

Значение параметра code	Описание
HCBT_ACTIVATE	Фильтр вызывается перед активизацией любого окна. Если функция возвращает FALSE, окно активизируется, если TRUE — нет. Параметр wParam содержит идентификатор активизирующегося окна. Параметр lParam содержит указатель на структуру CBTACTIVATESTRUCT : Флаг fMouse содержит TRUE, если окно активизируется в результате щелчка мыши, поле hWndActive содержит идентификатор активного окна
HCBT_CREATEWND	Фильтр вызывается перед созданием окна. Если функция фильтра возвращает FALSE, создание окна разрешается, если TRUE — нет. Параметр wParam содержит идентификатор создаваемого окна. Параметр lParam содержит дальний указатель LPCREATESTRUCT на структуру CREATESTRUCT :
HCBT_DESTROYWND	Фильтр вызывается перед уничтожением окна. Если функция возвращает TRUE, уничтожение окна отменяется. Параметр wParam содержит идентификатор уничтожаемого окна. Параметр lParam содержит 0
HCBT_MINMAX	Фильтр вызывается перед выполнением минимизации или максимизации окна. Если функция фильтра возвращает TRUE, перечисленные операции не выполняются. Параметр wParam содержит идентификатор окна, для которого выполняется минимизация или максимизация. Старшее слово параметра lParam равно нулю, младшее содержит одну из констант, описанных в файле windows.h с префиксом SW_, такие как SW_HIDE, SW_SHOWNORMAL, SW_SHOWMINIMIZED, SW_SHOWNOACTIVATE, SW_SHOW, SW_MINIMIZE, SW_SHOWMINNOACTIVE, SW_SHOWNA, SW_RESTORE
HCBT_MOVESIZE	Фильтр вызывается перед перемещением или изменением размера окна. Если функция фильтра возвращает TRUE, выполнение операции отменяется. Параметр wParam содержит идентификатор окна, для которого выполняется перемещение или изменение размера. Параметр lParam содержит дальний указатель на структуру RECT, описывающую прямоугольную область
HCBT_SYSCOMMAND	Фильтр вызывается при обработке системной команды. Вызов функции фильтра выполняется из функции DefWindowProc. Если функция фильтра возвращает TRUE, выполнение системной команды отменяется. Параметр wParam содержит код системной команды, такой, как SC_CLOSE, SC_HSCROLL, SC_MINIMIZE и т. д.Если параметр wParam содержит код команды SC_HOTKEY (активизация окна, связанного с клавишей ускоренного выбора, назначенной приложением), младшее слово параметра lParam содержит идентификатор окна, для которого назначена клавиша ускоренного выбора. Для остальных команд значение этого параметра не определено
HCBT_CLICKSKIPPED	Фильтр вызывается при удалении сообщения мыши из системной очереди сообщений, при условии, что дополнительно определен фильтр WH_MOUSE. Параметр wParam содержит код сообщения мыши. Параметр lParam содержит дальний указатель на структуру MOUSEHOOKSTRUCT :
HCBT_KEYSKIPPED	Фильтр вызывается при удалении клавиатурного сообщения из системной очереди сообщений, при условии, что дополнительно определен фильтр WH_KEYBOARD. Параметр wParam содержит виртуальный код клавиши.содержимое параметра lParam аналогично содержимому соответствующего параметра клавиатурных сообщений WM_KEYDOWN и WM_KEYUP
HCBT_SETFOCUS	Фильтр вызывается при установке фокуса ввода. Если функция фильтра возвращает значение TRUE, фокус не устанавливается. Параметр wParam содержит идентификатор окна, получающего фокус ввода. Младшее слово парамера lParam содержит идентификатор окна, теряющего фокус ввода. Старшее слово парамера lParam всегда содержит NULL
HCBT_QS	Фильтр вызывается при удалении из системной очереди сообщения WM_QUEUESYNC, предназначенного для использования обучающим приложением. Это сообщение позволяет ему определить момент завершения того или иного события в главном приложении. Тех, кого интересуют подробности, мы отсылаем к документации, поставляющейся вместе с SDK

Фильтр WH_DEBUG

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

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

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

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

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

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

Фильтр WH_GETMESSAGE

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

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

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

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

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

Фильтр WH_HARDWARE

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

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

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

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

Фильтр WH_JOURNALRECORD

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

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

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

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

Значение параметра code	Описание
HC_ACTION	Windows извлекает сообщение из системной очереди
HC_SYSMODALON	Windows выводит на экран системную модальную диалоговую панель. Начиная с этого момента приложение должно остановить запись сообщений
HC_SYSMODALOFF	Windows удаляет системную модальную диалоговую панель, так что теперь можно продолжить запись сообщений

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

Фильтр WH_JOURNALPLAYBACK

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

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

Перед возвратом управления функция фильтра 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:

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

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

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

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

Бит	Описание
0-15	Счетчик повторов. Если нажать клавишу и держать ее в нажатом состоянии, несколько сообщений WM_KEYDOWN и WM_SYSKEYDOWN будут слиты в одно. Количество объединенных таким образом сообщений
16-23	OEM скан-код клавиши. Изготовители аппаратуры (OEM — Original Equipment Manufacturer) могут заложить в своей клавиатуре различное соответствие скан-кодов и обозначений клавиш. Скан-код генерируется клавиатурным контроллером. Это тот самый код, который получают в регистре AH программы MS-DOS, вызывая прерывание INT16h
24	Флаг расширенной клавиатуры. Этот бит установлен в 1, если сообщение соответствует клавише, имеющейся только на расширенной 101- или 102-клавишной клавиатуре. Это может быть одна из следующих клавиш: , , , , , клавиши дополнительной клавиатуры.
25-26	Не используются
27-28	Зарезервированы для использования Windows
29	Код контекста. Этот бит равен 1, если сообщение соответствует комбинации клавиши с любой другой, и 0 в противном случае
30	Предыдущее состояние клавиши. Если перед приходом сообщения клавиша, соответствующая сообщению, была в нажатом состоянии, этот бит равен 1. В противном случае бит равен 0
31	Флаг изменения состояния клавиши (transition state). Если клавиша была нажата, бит равен 0, если отпущена — 1

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

Фильтр WH_MOUSE

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

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

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

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

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

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

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

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

Фильтр WH_MSGFILTER

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

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

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

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

Фильтр WH_SYSMSGFILTER

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

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

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

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

Фильтр WH_SHELL

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

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

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

Значение параметра code	Описание
HSHELL_ACTIVATESHELLWINDOW	Оболочка должна активизировать свое главное окно
HSHELL_WINDOWCREATED	Создано окно верхнего уровня, которое не принадлежит ни одному приложению. Это окно будет существовать во время работы функции фильтра. Идентификатор созданного окна передается через параметр wParam
HSHELL_WINDOWDESTROYED	Описанное выше окно верхнего уровня будет уничтожено после завершения работы функции фильтра. Идентификатор уничтожаемого окна передается через параметр wParam

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Значение	Описание
HWND_BOTTOM	Окно следует расположить под другими окнами
HWND_TOP	Окно будет расположено над другими окнами
HWND_TOPMOST	Окно следует расположить над всеми другими окнами, имеющими расположение HWND_TOPMOST
HWND_NOTOPMOST	Окно будет расположено над всеми HWND_TOP-окнами, но под окном, имеющим расположение HWND_TOPMOST

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

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

Значение	Описание
SWP_DRAWFRAME	Следует нарисовать рамку, определенную в классе окна
SWP_HIDEWINDOW	Окно будет скрыто
SWP_NOACTIVATE	Окно не будет активизировано
SWP_NOMOVE	Окно не будет перемещаться, при указании этого флага параметры x и y игнорируются
SWP_NOSIZE	Окно не будет изменять свои размеры, параметры cx и cy игнорируются
SWP_NOREDRAW	Не следует выполнять перерисовку окна. После перемещения приложение должно перерисовать окно самостоятельно
SWP_NOZORDER	Не следует изменять расположение окна относительно других окон, параметр hwndInsertAfter игнорируется
SWP_SHOWWINDOW	Отобразить окно

После перемещения и изменения расположения главного окна функция 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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