На чем и как

Крис Касперски ака мыщъх

Спецвыпуск: Хакер, номер #053, стр. 053-056-4

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

Работу можно считать законченной, когда в вычислительной части не останется ни одного прямого вызова API-функции. Обертки в основном пишутся на С с редкими вкраплениями ассемблера и оформляются как DLL или статически компонуемый модуль. Опытные программисты используют одну и ту же библиотечку для всех своих проектов, поэтому DLL в большинстве случаев все же предпочтительнее (но не забывай, что большое количество явно прилинкованных DLL ощутимо замедляет загрузку приложения). Использовать С с плюсами здесь в общем нежелательно. Во-первых, исходный текст получается избыточнее, а во-вторых, "манглеж" приплюснутых имен не стандартизирован. Динамическую библиотеку, скопированную Borland C++, к проектам Visual C++ подключить совсем не просто (впрочем как и наоборот). Pascal же здесь категорически непригоден: отсутствует нормальный интерфейс с операционной системой, это вынуждает ходить окружным путем, то есть через пятую точку.

Иногда возникает необходимость обратиться к защищенным ресурсам, доступным только из режима ядра (например, вызвать привилегированную команду процессора). Программисты старшего поколения в этом случае пишут псевдодрайвер. С точки зрения операционной системы псевдодрайвер выглядит как обыкновенный драйвер, но, в отличие от него, не управляет никакими устройствами, а просто выполняет привилегированный код, общаясь с прикладным приложением через интерфейс IOCTL. Псевдодрайверы пишутся на С с небольшой примесью ассемблера. Чистый ассемблер более элегантен, но экономически невыгоден. Приплюснутый С скрывает подводные камни. Не используй его, если точно не уверен, что именно ты делаешь. Для облегчения разработки драйверов фирма NuMega выпустила пакет Driver Studio, и хотя многие от него без ума, общее впечатление отрицательное. Лучше купи "Недокументированные возможности Windows 2000" Свена Шрайбера. Там ты найдешь готовый скелет псевдодрайвера, который легко адаптировать под свои нужды, не отвлекаясь на изучение посторонних дисциплин. Еще можно использовать готовые библиотеки, дающие с прикладного уровня доступ к портами и прочим системным компонентам (исходный текст одной такой библиотеки приведен в моей книге "Техника защиты лазерных дисков от копирования"). Естественно, такой подход небезопасен и совсем не элегантен.