У проекту Plug and Play було кілька основних завдань, які повинні були вирішити сама специфікація і будь-які її втілення. Найголовніша мета полягала в тому, щоб не тільки полегшити додавання до системи нових апаратних засобів або зміна конфігурації вже підключених пристроїв, але і гранично спростити ці дії. Користувачі змінюють конфігурацію пристроїв швидше, ніж раніше і не відчувають при цьому роздратування, а значить, набагато менше переживань випадає на долю груп підтримки, в які зазвичай телефонують користувачі, якщо у них щось не виходить. У розробників апаратних засобів з'являється чіткий стандарт, з яким вони можуть слідувати замість того, щоб намагатися самим вирішувати всі потенційні проблеми, пов'язані з установкою і конфігурацією. У разі якщо всі нові апаратні засоби будуть розроблятися відповідно до стандарту Plug and Play, стає цілком реальною ситуація, при якій всі, що залишиться зробити для додавання пристрою до сис-темі - це підключити його і скопіювати на жорсткий диск все необхідне програмне забезпечення. З існуючих в даний час програмним забезпеченням досягти такого рівня простоти дуже складно, оскільки апаратні засоби не відповідають стандарту Plug and Play. Втім, можна зробити дуже багато в сенсі поліпшення програмного забезпечення, і стандарт Plug and Play дійсно сприяє вдосконаленню драйверів пристроїв, які можуть дозволити існуючим відповідним ISA апаратних засобів піддаватися управлінню в середовищі Plug and Play.
Специфікація Plug and Play налічує п'ять цілей:
1. Простота установки і конфігурації нових пристроїв.
2. Єдині динамічні зміни конфігурації.
3. Сумісність з вже встановленими пристроями.
4. Незалежність від апаратних засобів і операційної системи.
5. Спрощеність і підвищена гнучкість апаратної реалізації.
В межах підсистеми Plug and Play взаємодіє безліч модулів, основні з яких показані на малюнку 3.20.
Функціональне призначення елементів:
1. Дерево апаратних засобів. Це база даних, в якій міститься інформація про поточну конфігурацію системи, будів-ится диспетчером конфігурації і зберігається в пам'яті. Кожна вершина дерева називається вузлом пристрою (device node) і містить логічне опис або конкретного пристрою, або шини.
2. INF-файли - це набір дискових файлів, що містять інформацію про конкретних типах пристроїв. Наприклад, у файлі SCSI.INF зберігається інформація про всі відомі SCSI-пристроях. В ході установки нового пристрою, відповідного Plug and Play, буде використаний новий .INF-файл. Зазвичай такий файл знаходиться на дискеті, що поставляється разом з пристроєм.
Мал. 3.20. Складові підсистеми Plug and Play
3. Реєстр. Дерево апаратних засобів, яке описує пристрої, входить до складу реєстру Windows 9х як поддерево.
4. Події - це набір функцій API, іспользуюемих для повідомлення про зміни поточної конфігурації системи. У Windows 9х про події сигналізує система повідомлень. В інших реалізаціях про них може повідомляти один з компонентів операційної системи.
5. Диспетчер конфігурації. Цей модуль відповідає за побудову бази даних, в якій міститься інформація про конфігурацію комп'ютера, що поміщається в реєстр, і за повідомлення драйверів пристроїв про те, які ресурси їм виділені. Диспетчер конфігурації при роботі системи являє собою центральний модуль підсистеми Plug and Play.
6. Енумератор (Enumerator). Це новий тип драйвера, який взаємодіє з драйвером пристрою і з диспетчером конфігурації. Енумератор обслуговує конкретний пристрій (зазвичай шину), до якого можуть підключатися інші пристрої. З кожним описаним в дереві апаратних засобів пристроєм шини пов'язаний свій енумератор. Особливий енумератор (root enumerator), названий кореневим, входить до складу диспетчера конфігурації. Він допомагає налаштовувати пристрої, які не відповідають стандарту Plug and Play.
7. Арбітр ресурсів. Цей модуль відповідає за управління виділенням конкретних ресурсів і запобігання конфліктів.
9. Драйвери пристроїв Plug and Play. Це драйвери захищеного режиму, які відповідають за управління пристроями і, крім того, беруть участь в роботі підсистеми Plug and Play.
10. Інтерфейс користувача - набір стандартних діалогових вікон, що служать для отримання інформації в тих випадках, коли підсистемі Plug and Play для конфігурації необхідна допомога користувача. Вони дають користувачеві можливість ознайомитися з конфігурацією системи, яку будує підсистема Plug and Play.
11. Додаток. З точки зору стандарту Plug and Play, це написана для Windows 9х програма, яка здатна сприймати і обробляти повідомлення системи про зміну конфігурації.
Діяльність підсистеми Plug and Play складається, головним чином, в тому, що вона від імені різних пристроїв управляє чотирма видами ресурсів:
1. Пам'ять. Йдеться про вимоги пристроїв до фізичної пам'яті, наприклад, скільки сторінок пам'яті потрібно пристрою і які обмеження по вирівнюванню.
2. Введення-виведення. Це порти введення-виведення, через які відбуватиметься робота з пристроєм. Інформація про конфігурацію пристрою включає перелік альтернативних наборів портів.
3. DMA - список необхідних пристрою каналів прямого доступу до пам'яті і будь-яких альтернативних каналів, які воно може використати.
4. IRO - вимоги пристрої до лінії запиту переривань, альтернативні IRQ, а також відомості про те, чи може пристрій використовувати IRQ як розділяється ресурс.
Підсистема Plug and Play включає безліч модулів, написаних на Сі і Ассемблері. Більшість своїх компонентів система завантажує динамічно. Головним елементом підсистеми Plug and Play є дерево апаратних засобів, що описує поточну конфігурацію системи.
Припустимо, що не вносилося ніяких змін в конфігурацію системи з того моменту, коли в останній раз з нею працювали. Подивимося, що станеться, якщо включити харчування.
1. Системна BIOS "заглядає" в незалежне пристрій (СМ OS) і визначає конфігурацію комп'ютера. Потім BIOS конфигурирует всі пристрої, для яких їй вдається виявити відповідну інформацію; в даному випадку мова йде про пристрої материнської плати. При цьому BIOS відключає всі адаптери, для яких відсутня інформація про конфігурацію.
2. Починається процес завантаження. Система як і раніше працює в реальному режимі. Кореневої енумератор диспетчера конфігурації використовує поддерево апаратних засобів з реєстру Windows для довідки про те, якою має бути конфігурація системи.
3. Кореневий енумератор переглядає поддерево реєстру в пошуках інформації про пристрої, які не відповідають стандартам Plug and Play. Виявивши чергове такий пристрій, він створює вузол пристрою і додає його до кореня зберігається в пам'яті дерева апаратних засобів. Крім того, кореневої енумератор конфигурирует все ті пристрої, що не сконфігурованої BIOS.
4. Триває завантаження системи в реальному режимі. Системний завантажувач обробляє файл SYSTEM.INI і завантажує всі зазначені в ньому статичні віртуальні драйвери зовнішніх пристроїв.
5. Після цього завантажуються інші енумератори. Наприклад, BIOS зазначила той факт, що до складу системи входить шина ISA. У реєстрі вказано, який енумератор слід завантажити для даної шини.
6. Енумератор вивчає підключені до шини пристрої і завантажує або статичний VЧD (якщо такий необхідний), або ще один енумератор, якщо необхідно обстежити додаткову шину.
7. Тепер в пам'яті вже знаходяться всі необхідні драйвери реального режиму і статичні VЧD. Ядро операційної системи закінчує свою власну ініціалізацію і перемикається в захищений режим.
8. Запускається диспетчер конфігурації. Деякі з підключених до системи пристроїв вже повністю проініціалізовані і їх драйвери вже завантажені. Про інші пристрої система вже знає, але їх драйвери ще не завантажені.
9. Диспетчер конфігурації завантажує потрібні енумератори, які, в свою чергу, вивчають підключені пристрої і приєднують до дерева апаратних засобів нові вузли. Після закінчення цього процесу диспетчер конфігурації завантажує драйвери, що відповідають новим вузлів пристроїв. Саме на цьому етапі стає відомо про всі можливі конфлікти, і приймаються відповідні рішення.
10. Якщо після всіх цих дій залишиться якусь непізнане, що не підтримує стандарт Plug and Play пристрій, Windows починає процес його установки, в ході якого користувачеві доводиться допомагати системі розібратися з конфігурацією. Якщо необхідності в цьому не виникає, система починає працювати.
5. Жигарев А. Основи комп'ютерної грамоти. - Л. Машинобудування, 1988. - 285 с.
7. Каранчук В. та ін. Основи застосування ЕОМ. - М. Радіо і зв'язок, 1988. - 276 с.
9. Медник С. Захист ЕОМ. - М. Мир, 1982. - 263 с.
11. СТ ІСО 2382 / 1-84.
19. Хоффман Л. Сучасні методи захисту інформації: Пер. з англ. / Под ред. Герасименко В. А. - М. Радянське радіо, 1980. - 263 с.
22. Шураков В. Забезпечення збереження інформації в системах обробки даних. - М. Фінанси і статистика, 1985. - 224 с.