Наши друзья:

Утилита BUILD

Для построения драйверов и связанных с ними прикладных программ используется утилита BUILD, входящая в состав DDK. Эта утилита позволяет создавать любой тип исполняемого файла, поддерживаемый NT с использованием командной строки. Стандартного (и поддерживаемого Microsoft) способа использования Интегрированной Среды Разработки для написания драйвера не существует. (Варианты, иллюстрирующие то, как это можно сделать, мы рассмотрим в следующем разделе.)
Возможны два варианта построения драйвера:
· Checked build - эквивалент Debug build в интегрированной среде;
· Free build, также называемый Retail build — эквивалент Release build в интегрированной среде.
Для осуществления конкретного построения необходимо запустить файл setenv.bat с соответствующими параметрами. С целью автоматизации этого процесса при установке DDK создаются ярлыки «Checked Build Environment» и «Free Build Environment». Запуск любого из них вызывает командную оболочку, из которой необходимо вызывать команду build.
Для успешной работы команды build в текущей директории должны находиться два специальных файла: SOURCES и DIRS.
Файл SOURCES является аналогом понятия проект. В нем определяется имя создаваемого модуля, его тип, корневая директория, где будет размещен результат, путь поиска include-файлов, список подключаемых библиотек и список файлов с исходным текстом.
Файл DIRS определяет список поддиректорий, которые должны быть обработаны командой build, прежде чем перейти к текущей директории. Директория, в которой запускается команда build, может содержать либо файл SOURCES, либо файл DIRS, либо оба вместе. Отсутствие файлов является ошибкой.
Директория, в которой содержится только файл DIRS, не будет обработана командой build, но будут обработаны все поддиректории из файла DIRS.
Директория, в которой содержится только файл SOURCES, будет обработана командой build, но ни одна поддиректория обработана не будет.
Директория, в которой содержатся оба файла, будет обработана командой build только после обработки всех поддиректорий из файла DIRS.
Примеры файлов можно посмотреть в DDK, а полное описание утилиты build и структуры файлов - в документации к IPS Kit (В принципе, можно воспользоваться документацией к DDK, однако там описание менее понятно.)
Теперь рассмотрим некоторые отличия checked и free build. Как ясно из названия, это отладочный и окончательный варианты драйвера. Соответственно, они отличаются режимами оптимизации кода. Для режима checked создается отладочная информация в формате dbg, которую можно использовать для отладки в символьном режиме с помощью Softlce. В режиме checked на этапе компиляции определено имя DBG, которое может быть использовано директивами
#if DBG
...
#else
...
fendif
для выполнения действий, специфичных для checked или free версий драйвера. Типичным примером является обрамление таким способом функции DbgPrintO, которая выводит трассировочную информацию. Функция работает и в checked, и в free build, однако с помощью такой проверки ее можно исключить из free build.
Хорошо известная техника Microsoft по написанию кода - использование макроса ASSERTQ. Этот макрос проверяет условие. Если оно ложно, генерируется прерывание. При этом отладчику сообщается имя файла с исходным текстом и номер строки с макросом. Макрос работает только в checked-версии драйвера, установленного на checked-версии ОС. Во всех остальных случаях ничего не происходит.
При создании серьезного продукта цикл разработки драйвера выглядит примерно так:
1. 1. написание кода;
2. 2. проверка и отладка отладочной версии драйвера на отладочной версии ОС;
3. 3. проверка и отладка отладочной версии драйвера на рабочей версии ОС;
4. 4. проверка рабочей версии драйвера на рабочей версии ОС;
5. 5. проверка работы на многопроцессорной системе.
Особо обратите внимание на последний пункт. Нет никакого другого способа убедиться в корректной работе драйвера на многопроцессорной системе, кроме его тестирования на такой системе, даже при условии корректной работы драйвера на однопроцессорной системе.

С и C++. Интегрированная среда разработки

Необходимо особо отметить, что драйверы предполагается писать на С, а не на C++. Microsoft не поддерживает использование C++ для компонентов ядра. Для этого имеется ряд причин:
· отсутствие библиотеки времени исполнения (runtime library), а, следовательно, и определяемых в ней глобальных операторов new и delete4;
· отсутствие поддержки исключительных ситуаций C++;
· нет поддержки инициализации глобальных экземпляров классов.
В принципе, все эти проблемы разрешимы. Не будем останавливаться на описании конкретных способов. Об этом вы можете узнать в статье «C++ Runtime Support for the NT DDK», а также из анализа заголовочных файлов в продукте DriverWorks (в особенности файла vdw.h).
Как было сказано выше, интегрированная среда Developer Studio не имеет поддержки для создания драйверов. Драйверы компилируются из командной строки с использованием утилиты BUILD, поставляемой в составе DDK.
Реализовать поддержку драйверов из интегрированной среды можно несколькими способами:
· реализацией собственного АррWizard (см. АррWizard Programming Reference);
· созданием проекта на основе make-файла с вызовом собственного командного файла.
Этот файл должен:
· произвести настройку переменных окружения с помощью вызова setenv.bat из DDK;
· перейти в директорию с исходным текстом и вызвать утилиту build (см. также статью «Integrating BUILD and Developer Studio» в директории NT Insider).
Реализация собственного Арр Wizard - довольно непростая задача, однако, можно воспользоваться готовым из DriverWorks. Последовательность действий такая: выберите меню Developer Studio File\New... . В появившемся окне на закладке Projects выберите NT/WDM Driver (DriverWorks). В появившемся окне Мастера укажите тип драйвера NT и следуйте инструкциям, внося минимальные изменения. По завершении работы мастера удалите все созданные им срр- и h-файлы, и вставьте собственные с- и h-файлы.