Утилита 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. написание кода;
- 2. проверка и отладка отладочной версии драйвера на отладочной
версии ОС;
- 3. проверка и отладка отладочной версии драйвера на рабочей
версии ОС;
- 4. проверка рабочей версии драйвера на рабочей версии
ОС;
- 5. проверка работы на многопроцессорной системе.
Особо обратите внимание на последний пункт. Нет никакого
другого способа убедиться в корректной работе драйвера на многопроцессорной
системе, кроме его тестирования на такой системе, даже при условии корректной
работы драйвера на однопроцессорной системе. |
