Теория разработки драйверов

Автор работы: Пользователь скрыл имя, 04 Января 2011 в 19:53, курсовая работа

Описание работы

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

Файлы: 1 файл

Курсовик.docx

— 112.28 Кб (Скачать файл)

     Принтер вызывает функцию EndDocPort после того, как задание завершено. Мониторы должны вызвать Win32-функцию SetJob для того, чтобы проинформировать спулер о завершении  работы. Функция монитора порта EndDocPort должна вызвать SetJob с параметром dwComand, установленным в JOB_CONTROL_SENT_TO_PRINTER. Когда работа принтера проходит через «языковый» монитор, спулер игнорирует любые оповещения, получаемые от монитора порта. Следовательно, монитор, который может определить реальное окончание работы принтера, должен задержать вызов SetJob до тех пор, пока принтер не уведомит об окончании работы. Для этой цели может использоваться функция EndDocPort. Language-монитор должен передать JOB_CONTROL_LAST_PAGE_ELECTED, когда он получает уведомление от принтера об окончании работы. Мониторам может понадобиться изменить это, если пользователь убирал или перезапускал задание. Для того, чтобы определить происхождение этого события, нужно вызвать Win32-функцию GetJob и проверить, не установлен ли статус работы в JOB_STATUS_DELETING или JOB_STATUS_RESTART. Функция EndDocPort также должна освободить все ресурсы, выделенные функцией StarDoc.

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

     Спулер  вызывает функция DeletePort для удаления порта из окружения монитора. Монитор должен удалить указанный порт из своего состояния.

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

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

     Функция SetPortTimeOuts необязательная, она устанавливает тайм-аут ожидания ответа порта.

     Функция GetPrinterDataFromPort тоже необязательная, она получает данные принтера из порта. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     Часть 6. Написание 64-битных драйверов

     6.1. 64-битные ОС. Преимущества и недостатки.

     64-битная  ОС для своей работы требует  использование 64-битного процессора. Большинство 64-битных систем могут  выполнять 32-битное программное  обеспечение в так называемом "режиме совместимости", который  важен по причине того факта,  что "родные" 64-битные приложения  всё ещё встречаются довольно  редко. Процессор при необходимости  переключается в 32-битный режим.  Запуск же 32-битной ОС на 64-битном CPU обычно приводит к тому, что  процессор всё время работает  в наследственном режиме. Если 64-битное  программное обеспечение может  на 64-битной ОС работать быстрее  (если оно должным образом оптимизировано), то 32-битные приложения на 64-битных  ОС обычно дают прежний уровень  производительности. 

     Недостатком 64-битных вычислений является другая модель памяти, а также отсутствие 64-битных приложений в целом. Низкоуровневые компоненты, такие как драйверы, доступны не для всех устройств, с  которыми вы планируете работать. Что касается поддержки 32-битного ввода/вывода в 64-битных драйверах, то подсистема WOW 64 позволяет 32-битным драйверам запускаться под 64-битной Windows. Но эта подсистема работает  только для приложений, для драйверов эта система не работает. Почти все они не могут выполняться в 32-битном режиме совместимости.

     Преимущества 64 бит.

     - 32-битная версия Windows ограничена поддержкой максимум 4 Гбайт памяти, и даже при этом она не будет отдавать весь объём вашим приложениям - система Windows будет использовать часть памяти для собственных нужд, в результате вы получите 3 Гбайт или чуть больше. Поэтому максимальный объём памяти 32-битной Windows на самом деле ограничен 3+ Гбайт. 64-битная версия Windows будет поддерживать любой объём памяти, доступный сегодня. 

     - 4-битные ОС с большим количеством памяти лучше работают с большими файлами. Представьте себе 5-Гбайт файл под 32-битной версией Windows, где доступно всего 3 Гбайт памяти: системе придётся работать с файлом, загружая его в память по частям.

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

     6.2 Требования к драйверу

     - драйвер не может быть модифицировать код ядра во время выполнения

     - драйвер не может модифицировать такие таблицы, как IDT и GDT

     -  драйвер не может модифицировать недокументированные структуры ядра

     - драйвер не может создавать и использовать свой собственный стек

     Это главные правила. Теперь о соглашении о вызовах (Calling convention) 64-битных драйверов.

     Существуют  три типа СС: STDCALL, FASTCAL, CDECL.

     CDECL – один из типов соглашения от вызовов, являющихся стандартным для программ на языках С и С++. Аргументы передаются через стек, справа налево, вызванная функция забирает аргументы из стека. Отличается от STDCALL, прежде всего тем, что генерирует исполняемые файлы заметно большего размера. Это происходит потому, что в CDECL любой вызывающий код должен включать в себя функциональность по очистке стека.

     FASTCAL – характеризуется тем, что первые два аргумента передаются через регистры ECX и EDX. Остальные аргументы передаются через стек справа налево. Вызванная функция забирает аргументы из стека.

     STDCALL – характеризуется тем, что вызывающая функция «кладет» параметры, передаваемые подпрограмме, в стек справа налево. Аргументы по умолчанию передаются по значению. Вызванная функция «забирает» свои параметры из стека.

     Ближе всего СС 64-битных систем к FASTCALL. Главные отличия от последнего – это 64-битная адресация и наличие шестнадцати 64-битных регистров.

     Биты, байты, слова и двойные слова  остались прежними. Теперь у нас  есть четвертные и восьмеричные слова  – это Quadword для 64 бит, и Octalword – размером 128 байт.

     Что касается поддержки 32-битного ввода/вывода в 64-битных драйверах, то подсистема WOW 64 позволяет 32-битным драйверам запускаться под 64-битной Windows. Но эта подсистема работает  только для приложений, для драйверов эта система не работает.

     Компиляторы 64-битных систем должны выполнять несколько  дополнительных функций - обеспечить поддержку  ANSI/ISO совместимости с языком С++, а кроме того, их компоновщики обязаны поддерживать оптимизацию так называемых «дальних переходов». Последняя опция позволяет компоновщику успешно работать с программами, регионы которых превышают 16 Мбайт.

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

     Ограничения 64-битного компилятора:

     -компиляторы  64-битных платформ генерируют  только низкоуровневый, «сырой»  код

     -больше  не поддерживаются проверки безопасности

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

     6.3 Портирование 32-битных драйверов на 64-битную платформу

     Цель  и концепция нового стиля программирования в 64-разрядной версии Windows – максимально унифицировать процесс разработки приложений одновременно и под 32-битную, и под 64-битную версии Windows. Такой принцип предполагается обеспечить для написания драйверов. Определенные шаги в этом направлении уже сделаны.

      Очень многие профессиональные С-программисты привыкли к тому, что целочисленный, long-типы и указатели одного размера (32 бита). Такой ситуации пришел конец – в новом 64-битном окружении типы не одинакового размера. Указатели приобрели длину 64 бита. Понятно, что это необходимо, т.к. возникла задача адресации объемов памяти больших 16 Тбайт. А изменять размеры стандартных типов данных пока что нет необходимости.

     Еще одна деталь: в 64-битной ОС Windows не работает больше механизм автоматического устранения ошибок выравнивания памяти (в режиме ядра); поэтому перед переносом своего 32-битного драйвера на 64-битную платформу необходимо исправить все такие ошибки в его коде.

     Новые типы данных. Они делятся на три  группы: целочисленные с фиксированной  точностью, целочисленные с точностью  указателя и целочисленные со специальной точностью. Все эти  типы выведены и стандартных типов  с – int и double. Всем разработчикам предлагается работать с новыми типами данных и проверять работу написанного кода на обеих платформах – 32-битной и 64-битной.

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

     Число -1 на 64-битной системе уже не равно 0xffffffff, как это было на 32-битной.

Оно равно 0xffffffffffffffff, в то время как 0xffffffff - это всего лишь 0x00000000ffffffff.

     -1 – это очень важная цифра в программировании, она используется очень часто для индикации ошибки. Например, функция поиска буквы «а» в строке может возвращать номер буквы «а», если она в строке есть и -1, если нет. 
 
 
 
 

     Часть 7. Windows Driver Foundation

     7.1 Новая драйверная модель

     WDM (Windows Driver Model) – это старая драйверная модель. Ей на смену постепенно идет ЦВА – новая драйверная модель компании Microsoft, которая использует возможности новых аппаратных и программных средств, устраняет недостатки старой модели, облегчает процесс написания драйверов.

     WDF работает только для следущих версий Windows:

  • Microsoft Windows 7
  • Microsoft Windows Vista
  • Microsoft Windows Server 2003
  • Microsoft Windows XP
  • Microsoft Windows 2000

    Особенности WDF:

     - новая драйверная модель простая и гибкая. Простая – для облегчения процесса написания драйверов, гибкая – для быстрой «адаптации» к новым возможностям системы.

     - драйверная модель не зависит от основных компонентов ОС (их изменение, добавление и т.д. не тянет за собой проблемы и/или вынужденные изменения при разработке драйверов)

     - драйверная модель поддерживает версионность, т.е. один исполняемый файл работает на разных ОС

     - драйверная модель легко расширяема

     - драйверная модель позволяет большинству драйверов успешно работать в пользовательском режиме

     - драйверная модель поддерживает написание драйверов на языках высшего уровня

     - драйверная модель позволяет легко писать, анализировать, верифицировать и т.д. DDI

     - драйверная модель умеет представлять для каждого драйвера отдельное называемое «защищенное окружение» (protected environment), или, уметь изолировать (driver isolation) 

     17.2 Особенности объектной модели WDF

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

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

     - объектная модель WDF предоставляет набор объектов, содержащих объекты, общие для любых драйверов – такие как устройства, очереди и т.д.

Информация о работе Теория разработки драйверов