Создание VxD на Visual C++ без ассемблерных модулей

Виртуальные драйверы устройств (VxD) в Windows во многих случаях являются единственным «честным» способом обхода ограничений, установленных системой для приложений Win32: невозможности прямого доступа к портам ввода-вывода и служебной памяти, эффективной обработки аппаратных прерываний, использования сервисных функций существующих VxD и т.п. Кроме того, без VxD не обходится практически ни один полноценный драйвер физического или виртуального устройства. Документация Microsoft и различные руководства по созданию VxD требуют, чтобы разработка велась на языке ассемблера. В то же время единственной официально поддерживаемой системой разработки является Microsoft Macro Assembler (MASM), синтаксис языка которого, а также надежность и удобство транслятора с начала 80-х годов оставляют желать лучшего. Гораздо более удобным средством разработки является Borland Turbo Assembler (TASM), особенно его режим Ideal, однако поставляемые Microsoft включаемые файлы, содержащие необходимые для драйвера определения, имеют множество специфических для MASM (и, честно говоря, чертовски уродливых) конструкций, что делает эти файлы непригодными для трансляции с помощью TASM.

На самом же деле использование языка ассемблера для разработки законченных программ под Windows совершенно бессмысленно. Любая из систем Windows вносит в работу компьютера просто чудовищные (сотни-тысячи процентов) накладные расходы, на фоне которых экономия нескольких десятков килобайт или нескольких тысяч тактов процессора на всю программу представляется каплей в море. Исключение составляют лишь отдельные, очень небольшие фрагменты программ, выполняемые в реальном времени сотни/тысячи раз в секунду, где экономия даже нескольких десятков тактов дает ощутимый рост эффективности. Такие фрагменты обычно оформляются в виде внешних ассемблерных модулей, или ассемблерных вставок в языках C/C++.

Microsoft не поддерживает средств разработки VxD на «чистых» C/C++; набор для разработки драйверов (DDK) для Windows 95 содержит некоторые файлы для создания отдельных модулей на этих языках, однако «костяк» VxD, по замыслу Microsoft, должен строиться на языке ассемблера. Сторонние фирмы выпускают библиотеки, облегчающие разработку VxD на C и C++ — VtoolsD/DriverStudio (NuMega), VxDWriter (TechSoft Pvt.), DriverX (Tetradyne Software) и т.п., однако каждая из этих библиотек построена по определенному принципу и налагает на программиста ряд не всегда удобных для него правил.

В то же время разработка VxD на «чистых» C/C++ не представляет абсолютно никакой сложности, если немного разобраться в структуре VxD и того кода, который создается компиляторами. Более того, 32-разрядные среды Microsoft Visual C++ изначально имеют возможность построения модулей VxD средствами самой среды, не прибегая к внешним трансляторам или утилитам.

Компилятор MS VC++ версии 4.1 содержал ошибку, не позволявшую строить правильные VxD, отчего распространилось мнение, будто это невозможно в принципе. Однако версии 4.0, 4.2, 5.x и 6.x могут быть успешно использованы для создания VxD без выхода из среды разработки.

Единственное, что невозможно сделать полностью на Visual C++ — это построить VxD, использующий 16-разрядный код, который 32-разрядный компилятор Visual C++ создавать не способен. 16-разрядный код необходим в процессе инициализации системы в фазе реального режима (real mode), а также при размещении фрагментов кода внутри виртуальных машин V86. В этом случае требуется подключение внешних ассемблерных модулей, транслируемых при помощи MASM или TASM, однако основная часть драйвера все равно может быть сделана в системе Visual C++.

В данной статье рассматриваются вопросы разработки VxD на «чистом» C++, в среде MS VC++ 4.2, свободной от упомянутой ошибки компилятора.

Статья ни в коей мере не претендует на полное описание вопросов разработки VxD. Здесь даны лишь основные сведения, позволяющие сделать работоспособный VxD «с нуля».

Документацию из Windows DDK можно найти в онлайновой библиотеке Microsoft.