[Previous] [Next]

Развитие спецификации Plug & Play

Два десятилетия бурного развития вычислительной техники, в течение которого доступ к компьютерам стал действительно массовым, завершились вполне закономерно. Функционально насыщенная аппаратура выполняет не только работу, для которой она приобретается (управление механизмами, ведение финансовой отчетности, проектирование, игры и т.п.), но и в высокой степени самостоятельно решает задачи второго плана — собственное конфигурирование и настройку.

В начале девяностых годов пользователь персонального компьютера должен был уметь настраивать свой ПК, экономно при этом расходуя запас "незанятых" прерываний, переставляя перемычки и меняя положение DIP-переключателей на дополнительный картах в поисках оптимального быстродействия. Предварительная подготовка касалась не только необходимого знания портов ввода/вывода, настроек режима прямого доступа к памяти. Необходимо было знать, насколько хорошо сочетаются программы (которые предполагается установить) как с имеющимся "железом", так и между собой. И так далее, и так далее, включая "разгон" процессоров и преодоление проблем перевода ОС и принтеров на родной язык...

Разумеется, о таких "пустяках", как возможность подсоединения новых устройств без выключения компьютера, не было речи вовсе! Максимум сервиса предлагали игровые программы, которые могли предложить "поиграть" настройками, спрашивая в конце каждой итерации "Слышите ли Вы звук в колонках?"

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

Решение пришло в виде разработки спецификации Plug and Play, согласно которой устройства должны выдерживать определенные механические и электрические нормы. Основное же требование Plug and Play состоит в том, что устройства должны уметь предоставлять идентификационную информацию о себе в формате, определенном для данного типа (PCI, USB, FireWire, CardBus) подключения.

С выходом Windows 95 (и появлением некоторых сдвигов в подходах к разработке аппаратной части) усилия были сконцентрированы на автоматизации конфигурирования системы при добавлении и удалении устройств. Эти попытки усилили тенденции перехода пользователей на Windows 95, что в свою очередь ускорило миграцию на 32-разрядные операционные системы Microsoft, в частности на Windows NT. Наконец, с выпуском Windows 2000 Microsoft реализовала законченную архитектуру Plug and Play для подсистем ввода/вывода.

В настоящее время подключение устройств по шинам USB, CardBus (модифицированная PCMCIA) и FireWire (IEEE-1394) при работающем основном компьютере является безопасным (и даже штатным) режимом работы. Драйверная архитектура Windows 2000/XP/2003 полностью поддерживает эти события "появления" в системе новых устройств, позволяя конфигурировать и делать их доступными для использования без выключения питания компьютера и перезагрузки операционной системы.

Главным плюсом использования методологии Plug and Play является обеспечение автоматической поддержки инсталляции и удаления системных устройств. Чтобы добиться этого, необходимо выполнить несколько условий.

Программные компоненты Plug and Play

В сообщество участников поддержки PnP в операционной системе входят:

Рис. 9.1
Программные PnP компоненты Windows 2000/XP

Роль Системного Реестра

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

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

Промежуточным решением для получения автоматически распознаваемых шин и аппаратуры было в ранних версиях NT расширение загрузочного процесса, во время которого в Системный Реестр включается информация об обнаруженном оборудовании. Таким образом, проходящий инициализацию драйвер в ходе работы DriverEntry получал возможность увидеть список автоматически обнаруженных на данный момент устройств и создать подходящие объекты устройств.

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

С выходом Windows 95, а затем и Windows 98, и Windows 2000, данная модель была преобразована в обратную. Устройства объявляли о себе сами, либо во время загрузки, либо во время "горячего" подключения (hot plug), таким образом, настаивая на установке соответствующего регистрируемого драйвера. Такой метод получил название "аппаратно-центричного".

Следует отметить, что в настоящий момент пользователь может самостоятельно инициировать установку драйвера для устройств, не поддерживающих PnP (или даже — "как бы" устройств "как бы" не поддерживающих, что было в примере драйвера Example.sys несуществующего устройства, глава 3). Соответствующая информация будет сохранена в Системном Реестре для последующих загрузок — иными словами, старый "драйверо-центричный" механизм сохранен.

Более того, информация о PnP устройствах, однажды обнаруженных системой полностью из Системного Реестра не удаляется, даже если устройство не будет подключено при следующей загрузке системы — система "помнит" обо всех ранее произведенных подключениях и установленных драйверах, что позволяет ей экономить время, если вдруг, после длительного перерыва, пользователь решит использовать это устройство снова (см. раздел HKLM\System\CurrentControlSet\Enum).

Изначально предназначенная для Windows 95, WDM модель поддерживала методологию PnP, что существенно отличало ее от драйверной модели Windows NT. Компания Microsoft настойчиво продвигалась к достижению совместимости драйверных сред, и в результате NT модель была дополнена поддержкой PnP. Родился обобщенный подход к драйверной среде для Windows 98 и Windows NT 5, а новая общая модель получила наименование Windows Driver Model (WDM).