Windows Driver Model
У обчислювальній техніці модель драйверів Windows (WDM) свого часу також відома як модель драйверів Win32 є каркасом для драйверів пристроїв, представлена у Windows 98 та Windows 2000 для заміни VxD, яка використовувалася в старіших версіях Windows, таких як Windows 95 та Windows 3.1x, а також моделі драйверів Windows NT.
Драйвери WDM організовані у стек і взаємодіють один з одним за допомогою пакетів запиту введення-виведення (IRP). Модель драйверів Microsoft Windows уніфікувала моделі драйверів для лінійки продуктів Windows 9x та Windows NT шляхом стандартизації вимог і зменшення обсягу коду, який потрібно було писати. Драйвери WDM не працюють в операційних системах, старіших за Windows 98 або Windows 2000, таких як Windows 95 (до оновлення OSR2, яке додає підтримку моделі WDM), Windows NT 4.0 та Windows 3.1. Відповідаючи WDM, драйвери можуть бути двійково сумісними та сумісними на рівні початкового коду між Windows 98, Windows 98 Second Edition, Windows Me, Windows 2000, Windows XP та Windows Server 2003 на комп'ютерах на базі x86. Драйвери WDM розроблені з урахуванням прямої сумісності, тому драйвер WDM може працювати у версії Windows, новішій за ту, для якої драйвер спочатку було написано, але при цьому драйвер не може скористатися жодними новими функціями, представленими у новій версії. WDM, як правило, не має зворотної сумісності, тобто не гарантується, що драйвер WDM працюватиме в будь-якій старішій версії Windows. Наприклад, Windows XP може використовувати драйвер, написаний для Windows 2000, але не використовуватиме жодних нових функцій WDM, представлених у Windows XP. Однак драйвер, написаний для Windows XP, може як завантажуватися, так і не завантажуватися у Windows 2000.
Про WDM було оголошено на WinHEC 1996 року, спочатку як про основну модель драйверів Windows NT 5.0.[1] WDM існує у проміжному шарі драйверів режиму ядра Windows 2000 і була представлена для розширення функціональності та спрощення написання драйверів для Windows. Хоча WDM переважно була розроблена для двійкової та програмної сумісності між Windows 98 і Windows 2000, це не завжди є бажаним, тому для кожної з операційних систем можна розробляти спеціальні драйвери.
За допомогою моделі драйверів Windows (WDM) для пристроїв Microsoft реалізує підхід до драйверів режиму ядра, унікальний для операційних систем Windows. WDM реалізує багаторівневу архітектуру для драйверів пристроїв, і кожен пристрій комп'ютера обслуговується стеком драйверів. Однак кожен драйвер у цьому стеку може відокремлювати апаратно-незалежні функції від драйвера, розташованого вище та нижче нього. Тому драйверам у стеку не потрібно безпосередньо взаємодіяти один з одним. WDM визначає архітектуру та процедури роботи з пристроями для низки пристроїв, таких як дисплей та мережева плата, відомих як Network Driver Interface Specification (NDIS). В архітектурі NDIS багаторівневі мережеві драйвери містять драйвери нижчого рівня, які керують апаратним забезпеченням, і драйвери верхнього рівня, які реалізують транспортування мережевих даних, наприклад Transmission Control Protocol (TCP).[2]
Хоча WDM визначає три типи драйверів пристроїв, не всі стеки драйверів для певного пристрою містять усі типи драйверів пристроїв. Трьома типами драйверів пристроїв WDM є:[2]
Драйвер шини: для кожної шини на системній платі існує один драйвер шини, основним завданням якого є ідентифікація всіх пристроїв, підключених до цієї шини, та реагування на події підключення та відтворення. Microsoft постачає драйвери шин як частину операційної системи,[2] наприклад для PCI, PnPISA, SCSI, USB та FireWire.
Функціональний драйвер: це основний драйвер пристрою, який забезпечує інтерфейс роботи з пристроєм шляхом обробки операцій читання та запису. Функціональні драйвери пишуться виробниками пристроїв, і для взаємодії з апаратним забезпеченням вони залежать від наявності відповідного драйвера шини в операційній системі Windows.[2]
Фільтрувальний драйвер: цей драйвер є необов'язковим і може змінювати поведінку пристрою, наприклад запити введення та виведення. Такі драйвери можуть реалізовуватися як фільтрувальні драйвери нижнього та верхнього рівнів.[2]
Функціональні драйвери та драйвери шин часто реалізуються як пари драйвер/міні-драйвер, які на практиці є або парою клас/мініклас, або порт/мініпорт.[3]
Драйвери шин для пристроїв, підключених до шини, реалізуються як драйвери класу та не залежать від конкретного апаратного забезпечення. Вони підтримують операції певного типу пристроїв. Операційні системи Windows містять низку драйверів класів, таких як драйвер kbdclass.sys для клавіатур. З іншого боку, мінікласові драйвери постачаються виробником пристрою та підтримують лише специфічні для пристрою операції для певного пристрою відповідного класу.[3]
Портові драйвери підтримують загальні операції введення-виведення (I/O) для периферійного апаратного інтерфейсу. Основна функціональність портових драйверів визначається операційною системою, і операційні системи Windows містять різноманітні портові драйвери. Наприклад, портовий драйвер i8042prt.sys для мікроконтролера 8042 підключає клавіатури PS/2 до периферійної шини системної плати. Мініпортові драйвери, як і мінікласові драйвери, постачаються виробниками апаратного забезпечення та підтримують лише специфічні для пристрою операції периферійного апаратного забезпечення, підключеного до порту на системній платі.[4][5]
Кожен драйвер, який обробляє запит введення-виведення для пристрою, має відповідний об'єкт, який завантажується в оперативну пам'ять. Об'єкт пристрою створюється операційною системою Windows на основі відповідного класу пристрою. Об'єкти пристроїв містять структури типу DEVICE_OBJECT, у яких зберігаються вказівники на їхні драйвери. Під час виконання ці вказівники використовуються для пошуку процедури диспетчеризації та функцій-членів драйвера. У стеку драйверів WDM об'єкт пристрою фільтрувального драйвера, відомий як верхній фільтр, отримує пакет запиту введення-виведення (IRP) для пристрою від диспетчера введення-виведення. Якщо верхній фільтрувальний драйвер не може обробити запит, він знаходить об'єкт драйвера на один рівень нижче у стеку драйверів. IRP передається вниз стеком драйверів шляхом виклику функції IoCallDriver(), і обробляється об'єктом пристрою функціонального драйвера, також відомим як функціональний об'єкт пристрою. Об'єкт пристрою функціонального драйвера, своєю чергою, може передати IRP нижньому фільтру, іншому об'єкту пристрою фільтра. Потім IRP може бути переданий далі вниз до драйвера шини, який працює як фізичний об'єкт пристрою. Об'єкт драйвера шини розташований у нижній частині стеку драйверів і взаємодіє з рівнем апаратних абстракцій, який є частиною ядра операційної системи Windows і дозволяє операційним системам Windows працювати на різноманітних процесорах, різних архітектурах блоків керування пам'яттю та різноманітних комп'ютерних системах із різними архітектурами шин введення-виведення.[6] Виконання IRP завершується, коли будь-який з об'єктів драйверів у стеку повертає запит диспетчеру введення-виведення з результатом і прапорцем стану.[7]
Середовище WDM було розроблено Microsoft для спрощення взаємодії між операційною системою та драйверами всередині ядра. В операційних системах Windows драйвери WDM реалізуються як файли DLL або .SYS у форматі Portable Executable. Сумісні з WDM драйвери повинні дотримуватися правил проєктування, ініціалізації, Plug and play, керування живленням і розподілу пам'яті. На практиці програмісти драйверів WDM повторно використовують великі частини коду під час створення нових об'єктно-орієнтованих драйверів. Це означає, що драйвери у стеку WDM можуть містити залишкову функціональність, яка не задокументована у специфікаціях.[7] Драйвери, які пройшли перевірку якості Microsoft, мають цифровий підпис Microsoft. Тести сумісності обладнання Microsoft та Driver Development Kit містять тести на надійність і стійкість до навантажень.[8]
Драйвер пристрою, який не призначений для конкретного апаратного компонента, може дозволити іншому пристрою функціонувати. Це пояснюється тим, що базова функціональність класу апаратних пристроїв є подібною. Наприклад, функціональність класу відеокарт дає змогу драйверу Microsoft Basic Display Adapter працювати з широким спектром відеокарт. Однак встановлення неправильного драйвера для пристрою означатиме, що повна функціональність пристрою не може бути використана, а також може призвести до низької продуктивності та нестабільності операційної системи Windows. Виробники апаратних пристроїв можуть випускати оновлені драйвери пристроїв для певних операційних систем Windows, щоб покращити продуктивність, додати функціональність або виправити помилки. Якщо пристрій не працює належним чином, слід завантажити найновіші драйвери пристрою з вебсайту виробника та встановити їх.[9]
Драйвери пристроїв призначені для певних версій операційної системи Windows, і драйвери пристроїв для попередньої версії Windows можуть неправильно працювати або взагалі не працювати з іншими версіями. Оскільки багато драйверів пристроїв працюють у режимі ядра, встановлення драйверів для попередньої версії операційної системи може призвести до нестабільності операційної системи Windows. Тому перенесення комп'ютера на новішу версію операційної системи Windows вимагає встановлення нових драйверів пристроїв для всіх апаратних компонентів. Пошук актуальних драйверів пристроїв та їх встановлення для Windows 10 створили додаткові складнощі в процесі переходу на нову версію.[9]
Поширені проблеми сумісності драйверів пристроїв включають: для 32-розрядної операційної системи Windows потрібен 32-бітний драйвер пристрою, а для 64-розрядної операційної системи Windows — 64-бітний драйвер пристрою. 64-розрядні драйвери пристроїв повинні мати підпис Microsoft, оскільки вони працюють у режимі ядра та мають необмежений доступ до апаратного забезпечення комп'ютера. Для операційних систем до Windows 10 Microsoft дозволяла виробникам самостійно підписувати свої 64-розрядні драйвери, припускаючи, що виробники провели тести сумісності. Однак тепер 64-розрядні драйвери Windows 10 повинні мати підпис Microsoft. Тому виробники пристроїв повинні надсилати свої драйвери до Microsoft для тестування та схвалення.
Пакет встановлення драйвера містить усі файли з каталогу .inf, і всі файли пакета повинні бути встановлені, інакше встановлення драйвера пристрою може завершитися невдало. Для версій операційної системи до Windows 10 не всі файли, необхідні для встановлення драйвера, включалися до пакета, оскільки ця вимога не виконувалася послідовно. Деякі програми встановлення драйверів пристроїв мають користувацький інтерфейс GUI, який часто вимагає введення користувачем параметрів. Відсутність користувацького інтерфейсу не означає, що встановлення драйвера пристрою не було успішним. Крім того, драйвери пристроїв Windows 10 не повинні містити користувацького інтерфейсу.
Network Driver Interface Specification (NDIS) 10.x використовується операційною системою Windows 10 для мережевих пристроїв. Драйвери мережевих пристроїв для Windows XP використовують NDIS 5.x і можуть працювати з наступними операційними системами Windows, але з міркувань продуктивності драйвери мережевих пристроїв повинні реалізовувати NDIS 6.0 або новішої версії.[9]
Диспетчер пристроїв є аплетом Панелі керування в операційних системах Microsoft Windows. Він дає змогу користувачам переглядати та контролювати апаратне забезпечення, під'єднане до комп'ютера. Він дає змогу користувачам переглядати та змінювати властивості апаратних пристроїв, а також є основним інструментом для керування драйверами пристроїв.[9]
Модель драйверів Windows, хоча й була значним удосконаленням порівняно з VxD та Windows NT Driver Model, які використовувалися раніше, зазнала критики з боку розробників програмного забезпечення для драйверів,[10] найбільш суттєво з таких причин:
- Взаємодія з подіями керування живленням та Plug and play є складною. Це може призвести до ситуацій, коли комп'ютери під керуванням Windows не можуть належним чином увійти в режим сну або вийти з нього через помилки в коді драйверів.
- Правильно реалізувати скасування операцій введення-виведення складно.[11]
- Для кожного драйвера потрібен складний шаблонний допоміжний код.
- Відсутня підтримка написання драйверів, що працюють суто в режимі користувача.
Також виникали численні питання щодо якості документації та прикладів, які надавала Microsoft.
Через ці проблеми Microsoft випустила новий набір середовищ на основі WDM, названий Windows Driver Frameworks (WDF; раніше Windows Driver Foundation), який включає Kernel-Mode Driver Framework (KMDF) та User-Mode Driver Framework (UMDF). Windows Vista підтримує як чистий WDM, так і новіший WDF. KMDF також доступний для завантаження для Windows XP та Windows 2000, тоді як UMDF доступний для Windows XP та новіших версій.
- Windows Driver Frameworks (WDF)
- Kernel-Mode Driver Framework (KMDF)
- User-Mode Driver Framework (UMDF)
- Windows Display Driver Model (WDDM)
- WDM Input Output Concepts – This article gives a high level overview of the I/O concepts as defined in the Windows Driver Model.
- Windows driver API basics – This article informs you about the basics behind sound card drivers such as WDM, ASIO, MME, DirectX, etc.
- Channel 9 Video – Interview with the Device Management and Installation team at Microsoft, primarily covering Plug-and-play.
- [Lecture Notes on Windows Kernel Programming у Wayback Machine (арх. March 3, 2016)] – Free lecture notes book fragment detailing basic creation of Windows Drivers, Kernel Mode programming, and Memory management
- ↑ Source, Microsoft (1 квітня 1996). Microsoft Announces Win32 Driver Model... Source (амер.). Процитовано 31 травня 2026.
- 1 2 3 4 5 Marco Vieira; Joao Carlos Cunha, ред. (2013). Dependable Computing: 14th European Workshop, EWDC 2013, Coimbra, Portugal, May 15–16, 2013, Proceedings. Springer. с. 64. ISBN 9783642387890.
- 1 2 Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. с. 460. ISBN 9781449661229.
- ↑ Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. с. 460. ISBN 9781449661229.
- ↑ Introduction to the Windows Driver Foundation. Microsoft Developer Network. 13 жовтня 2006. Процитовано 6 грудня 2010.
The device class-specific driver models are typically structured as a port driver written by Microsoft paired with a miniport driver written by an independent hardware vendor. The port driver does much of the work required for the device class, and the miniport driver supports device-specific characteristics.
- ↑ Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. с. 460—461. ISBN 9781449661229.
- 1 2 Dave Penkler; Manfred Reitenspiess; Francis Tam, ред. (2006). Service Availability: Third International Service Availability Symposium, ISAS 2006, Helsinki, Finland, May 15–16, 2006, Revised Selected Papers. Springer Science & Business Media. с. 124. ISBN 9783540687245.
- ↑ Dave Penkler; Manfred Reitenspiess; Francis Tam, ред. (2006). Service Availability: Third International Service Availability Symposium, ISAS 2006, Helsinki, Finland, May 15–16, 2006, Revised Selected Papers. Springer Science & Business Media. с. 132. ISBN 9783540687245.
- 1 2 3 4 Byron Wright; Leon Plesniarski (2016). Microsoft Specialist Guide to Microsoft Windows 10 (Exam 70-697, Configuring Windows Devices). Cengage Learning. с. 96. ISBN 9781285868578.
- ↑ Oney, Walter (6 травня 2003). Introducing Windows Driver Framework. Windows Driver Developer's Digest. Т. 1, № 3. Архів оригіналу за 25 січня 2016.
- ↑ I/O Completion/Cancellation Guidelines. MSDN. Microsoft. 5 травня 2003. Архів оригіналу за 9 лютого 2018. Процитовано 8 лютого 2018.
