Що таке дрова у комп'ютері. Як називається драйвер материнської плати

Дізнайтеся, як шукати потрібні драйвера для будь-яких пристроїв, підключених до Вашого комп'ютера, без особливих зусиль.

Незважаючи на те, що на дворі вже ХХI століття та комп'ютери є майже у всіх, багато хто ставиться до них, як до якогось недоторканного дива техніки. Причому, свято вірячи в те, що у них найкращий ПК (бо так сказав продавець:)), такі користувачі не встановлюють на нього жодних програм і не спроможні перевірити, а чи правда комп'ютер працює нормально.

Навіщо я? До того, що нещодавно довелося зіткнутися з нагодою, коли в одних товаришів майже півтора роки після покупки комп'ютера не стояло нормального драйвера відеокарти! Скарга була звичайна - "" :) А чому б йому не гальмувати, якщо драйвера немає?!!

Загалом, сьогодні перевірятимемо свої ПК на наявність у них усіх потрібних драйверів.

Що таке драйвер та як його встановити?

Драйвер – це набір програмних компонентів, які забезпечують нормальну взаємодію комп'ютера з підключеним до нього обладнанням та картами розширень. Іншими словами, це спеціальна службова програмаяка може передавати команди від периферії до процесора і назад.

Без драйвера підключене обладнання або взагалі не працюватиме (принтери, сканери та інша оргтехніка), або працюватиме, але не в оптимальному режимі (відеокарти, чіпсети і т.п.). Саме тому для нормальної роботи ПК мало просто перевстановити систему, важливо ще знайти драйвери для всіх її компонентів!

Поставлятися драйвер може у трьох варіантах:

1. інсталяційний файл EXE (або MSI);
2. графічна оболонка з можливістю масового вибору та встановлення;
3. набір бібліотек та службових файлів, доповнений INF-файлом.

Перший варіант поставки драйверів найчастіше зустрічається в Інтернеті та на установочних дисках, які йдуть у комплекті з придбаним Вами обладнанням. Достатньо завантажити (або відкрити на диску) та запустити EXE-файл, і перед нами з'явиться Майстер установки, який дозволить налаштувати все у покроковому режимі. У цьому випадку встановлення драйвера не складніше, ніж встановлення будь-якої програми.

Другий варіант поставки можна виявити, на дисках з різними збираннями, що містять кілька різних драйверів (наприклад, драйвера для материнської платиабо так звані драйвер паки). Такі зборки зазвичай дозволяють вибірково встановлювати окремі (або всі відразу) драйвери і не складніше звичних інсталяторів, але мають великий розмір.

Установка драйвера третім способом є найбільш неочевидною. Такі драйвера часто трапляються для старої технікиі не містять графічного інсталятора, зате включають файл (іноді і не один) з розширенням INF, в якому прописані всі шляхи встановлення пакета бібліотек для роботи обладнання, що підключається:

Щоб встановити драйвер в такий спосіб потрібно в "Диспетчері пристроїв" (значок "Комп'ютер" - ПКМ - "Властивості" (на старих системах вкладка "Обладнання")) викликати контекстне меню невідомого пристрою і вибрати пункт "Оновити драйвери".

Відкриється вікно, з якого ми маємо пройти такий шлях (натискаючи на відповідні кнопки): "Виконати пошук драйверів на цьому комп'ютері" - "Вибрати драйвер зі списку вже встановлених" - "Встановити з диска", а потім натиснути кнопку "Огляд" і вказати місцезнаходження потрібного Вам INF-файлу:

Після підтвердження вибору INF-файлу з'явиться повідомлення або про успішну установку, або про те, що вибраний файл не підходить і потрібно вибрати інший (якщо він є). Якщо жоден з INF-файлів не дає встановити потрібний драйвер, значить, Вам доведеться шукати альтернативне ПЗ або взагалі міняти обладнання або систему, щоб досягти сумісності пристрою з Вашим ПК.

Ну, а тепер, коли Ви знаєте, що таке драйвер, навіщо він потрібен і як його встановити, настав час розібратися зі способами пошуку драйверів.

Пошук за назвою пристрою

Будь-який пристрій (якщо це не якийсь безіменний китайський виріб) має свою назву. Знаючи цю назву та версію своєї системи, Ви, в більшості випадків, можете сформулювати правильний пошуковий запитдля введення у пошуковій системі. Наприклад: "драйвер принтера Canon IP1500 для Windows 7 64-bit" або "Radeon HD 8700M Windows 8 драйвер".

Результати пошукової видачі будуть містити сайти, з яких Ви можете завантажити потрібний драйвер. Однак не на всіх сайтах можна качати безкоштовно! Щоб уникнути непотрібних переживань через фінанси або встановлення неякісного софту, рекомендую Вам користуватися перевіреним російськомовним порталом:

На цьому сайті зібрано одну з найповніших колекцій драйверів з усього Інтернету сумарним об'ємом понад 300 ТБ! Тут можна шукати драйвер як за типом пристрою (основний список "Категорії обладнання"), так і за назвою виробника (алфавітний указівник у верхній частині сторінки).

На сторінці з потрібним компонентом буде низка варіантів завантажень. Звертайте увагу на поля "Тип програми" (там має бути слово "driver" інакше можете завантажити просто сервісну утиліту або плагін), "Опис" (там теж сказано, для чого потрібен той чи інший файл), а також "Система". Завантажити сам драйвер Ви можете за посиланням після опису, підтвердивши, що Ви не робот:)

Окрім пошуку драйверів на спеціалізованих репозиторіях, іноді має сенс шукати на сайтах розробників! Наприклад, драйвера під популярні відеокарти досить часто оновлюються та завантажити останню версіюВи можете часто лише на офіційному сайті. Тому наведу невеликий список посилань на сторінки завантаження драйверів від найпоширеніших марення.

Відеокарти:

Звукові карти:

Оргтехніка:

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

Пошук по ID пристрою

Пошук драйвера за назвою Вашого пристрою – досить просте завдання. Однак якщо сам пристрій від невідомого виробника, то і назви ми його знати ніяк не можемо! Якщо Ви зіткнулися з такою ситуацією, Вам допоможе альтернативний методпошуку – за ідентифікатором обладнання.

Кожен пристрій, хоч усередині системного блоку, хоч підключений зовнішнім кабелем, має у системі власний ідентифікатор чи ID. Дізнатися його ми можемо у вже знайомому нам "Диспетчері пристроїв", викликавши "Властивості" потрібного компонента, перейшовши на вкладку "Відомості" і вибравши у списку "Властивість" пункт "ІД обладнання" або "ID":

Починаючи з Windows Vista, Ви можете скопіювати значення рядка ідентифікатора в буфер обміну за допомогою контекстного меню. Більше ж ранніх версіяхфункції копіювання немає, тому ID доведеться переписувати вручну.

Тепер, знаючи ідентифікатор потрібного нам пристрою, ми можемо знайти відповідні драйвера за допомогою спеціалізованих сервісів. Тут нам знову може допомогти вже згаданий вище Driver.ru:

Для цього натисніть кнопку "Пошук" у правому верхньому куті і в полі на сторінці, що відкрилася, вставте скопійований ідентифікатор пристрою, після чого обов'язково позначте пункт "Пошук по ID" і натисніть кнопку "Пошук" під полем введення. Серед результатів, що відкрилися, Ви легко знайдете драйвер, що підходить для Вашої системи і зможете його скачати.

Аналогічно працює ще кілька великих порталів для пошуку драйверів. Найкращими є DevID.info і DevID.drp.su . До речі, обидва сервіси мають власні клієнти, що дозволяють автоматично визначати потрібні драйвери і встановлювати їх. Про подібне спеціалізованому софтіі поговоримо далі.

Програми для пошуку драйверів

Вище ми розглянули випадки коли шукати драйвери доводиться вручну. Однак, для цього також існують спеціальні програми, що дозволяють знаходити та качати все в автоматичному режимі. Усі їх можна поділити на два типи.

Програми першого типу є зазвичай невеликі (до десяти мегабайт) клієнтські модулі, які дозволяють просканувати комп'ютер на наявність застарілих чи не встановлених драйверів, а потім завантажити їх з Інтернету і встановити кілька кліків. У нас на сайті яскравим представником програм подібного роду є:

Однак, більшість подібних рішень мають один великий мінус: безкоштовно можна скачати тільки пару-трійку драйверів на добу. По перевищенню ліміту Вам або зовсім заборонять качати, або зменшать швидкість завантаження до мінімуму, щоб Ви зрештою все одно купили преміум-аккаунт.

З цієї причини програми цього виду безкоштовно можна використовувати тільки для одиничного оновлення драйверів, але не для пакетної установки на свіжовстановлену Windows. Якщо ж Ви хочете все і відразу, Ваш вибір - драйвер паки!

Драйвер пак (від англ. "driver pack" - "набір драйверів") являє собою, найчастіше, комплект з офлайн бази з відібраними драйверами та програми-оболонки. Програма сканує Ваш ПК, після чого пропонує встановити чи оновити низку драйверів. Вам достатньо лише відзначити потрібні та підтвердити свій вибір. Установка буде автоматично!

На просторах Рунета найповнішим і найпопулярнішим драйвер паком є:

На сьогоднішній день розмір максимального пакета постачання цього пакета драйверів складає більше ніж 10 гігабайт. Це не так вселяє, як 30-терабайтна база Driver.ru, але, однак, такої кількості драйверів цілком достатньо, щоб після переустановки системи не шукати настановні диски, які йшли в комплекті з материнською платою, відеокартою та іншими компонентами Вашого ПК чи ноутбука

Якщо качати 10 гігабайт драйверів Вам не хочеться, то є можливість завантажити Lite-версію DriverPack Online. Вона є лише програмою-сканером, яка визначає потрібні Вам драйвери, підключається до онлайн бази даних і дозволяє скачати тільки те, що потрібно.

Висновки

Сьогодні знайти драйвери для комп'ютера і ноутбука не складає особливих труднощів. Однак, як і будь-які програми, вони час від часу потребують оновлень, про які багато хто забуває. А, між іншим, оновлення можуть дуже допомогти!

Так, наприклад, у мене з весни час від часу став з'являтися "" зі скаргами на якусь DLL-бібліотеку. Якийсь час я мирився з таким станом речей, але потім набридло і я вирішив пошукати вирішення проблеми. Виявилося, що провиною була помилка в роботі драйвера відеокарти. Після оновлення драйвера все налагодилося і вже кілька місяців " політ " нормальний:)

Мораль всього вищевикладеного така: якщо у Вас раптом почалися "глюки" у роботі ПК або вони спостерігалися вже з моменту покупки комп'ютера пер установки Windows, перевірте, чи немає оновлень драйверів для критично важливих компонентівВаш комп'ютер. Якщо такі є, спробуйте їх встановити і, можливо, Ваша система знову запрацює як слід!

P.S. Дозволяється вільно копіювати та цитувати цю статтюза умови вказівки відкритого активного посилання на джерело та збереження авторства Руслана Тертишного.

Драйвери пристроїв забезпечують інтерфейс між ядром UNIX та апаратною частиною комп'ютера. Завдяки цьому від решти ядра приховані архітектурні особливості комп'ютера, що значно спрощує перенесення системи та підтримку роботи різних периферійних пристроїв.

У UNIX існує велика кількість драйверів. Частина забезпечує доступ до фізичних пристроїв, наприклад, жорсткого диска, принтера або терміналу, інші надають апаратно-незалежні послуги. Прикладом останніх можуть бути драйвери /dev/kmem для роботи з віртуальною пам'яттю ядра /dev/null, що представляє "нульовий" пристрій.

Під час запуску системи ядро ​​викликає відповідні процедури ініціалізації встановлених драйверів. У багатьох версіях UNIX ці процедури виводять на консоль повідомлення про те, що драйвер знайдено, і ініціалізація пройшла успішно, а також параметри драйвера та пристрою.

Типи драйверів

Драйвери розрізняються за можливостями, які вони надають, а також тим, яким чином забезпечується доступ до них та управління. Можна розглядати три основні типи драйверів:

Символьні.

Цей тип драйверів забезпечує роботу з пристроямиз драйвери побайтовим доступом та обміном даними. До таких пристроїв можна віднести модеми, термінали, принтери, маніпулятори миша і т.д.

Доступ до таких драйверів не включає використання буферного кешу, таким чином введення та виведення зазвичай не буферизується. При необхідності буферизації для символьних драйверів зазвичай використовується підхід, заснований на структурах даних, які називаються clist.

Блокові драйвери

Цей тип драйверів дозволяє здійснювати обмін даними з фіксованим пристроєм.порціями (блоками).

Наприклад, для жорсткого диска дані можна адресувати і, відповідно, читати лише секторами розмір яких становить кілька сотень байтів. Для блокових драйверів зазвичай використовується буферний кеш, який є інтерфейсом між файловою системою і пристроєм.

Хоча операції читання та записи для процесу допускають обмін даними, розмір яких менший за розмір блоку, на системному рівні це все одно призводить до зчитування всього блоку, зміни частини його даних і запису зміненого блоку назад на диск.

Драйвери низького рівня (raw drivers)

Цей тип інтерфейсу блокових драйверів дозволяє проводити обмін даними з блоковими пристроями, минаючи буферний кеш. Це, зокрема, означає, що пристрій може бути адресовано елементами розмір яких не збігається з розміром блоку.

Обмін даними відбувається незалежно від файлової підсистеми та буферного кеша, що дозволяє ядру робити передачу безпосередньо між процесом користувача і пристроєм, без додаткового копіювання.

На рис. 5.1 наведено спрощену схему взаємодії драйверів пристроїв з іншими підсистемами операційної системи UNIX.

Жорсткий диск Гнучкий дискТермінал

Мал. 5.1. Драйвери пристроїв UNIX

Не всі драйвери служать для роботи з фізичними пристроями, такими як адаптер мережі, послідовний порт або монітор. Частина драйверів служать для надання різних послуг ядра прикладним процесам і не мають безпосереднього відношення до апаратної частини комп'ютера. Такі драйвери називаються програмними або драйверами псевдопристроїв. Можна навести кілька прикладів псевдопристроїв та відповідних програмних драйверів:

/dev/mem /dev/nulf

Забезпечує доступ до віртуальної пам'яті ядра. Знаючи віртуальні адреси внутрішніх структур ядра, процес може зчитувати інформацію, що зберігається в них. За допомогою цього драйвера може, наприклад, бути реалізована версія утиліти s(1), що виводить інформацію про стан процесів у системі.

Забезпечує доступ до розділу файлу ядра, що містить таблицю символів. Спільно із драйвером /dev/kmem забезпечує зручний інтерфейсдля аналізу внутрішніх структур ядра.

Забезпечує доступ до фізичної пам'ятікомп'ютера.

Є "нульовим" пристроєм. При записі цього пристрою дані просто видаляються, а під час читання процесу повертається 0 байтів. Приклади використання пристрою розглядалися в розділі 1, коли за допомогою /dev/null ми пригнічували виведення повідомлень про помилки.

Забезпечує заповнення нулями вказаного буфера. Цей драйвер часто використовується для ініціалізації області пам'яті.

Драйвер пристрою адресується старшим номером (major number) пристрою. Нагадаємо, що серед атрибутів спеціальних файлів пристроїв, які забезпечують користувальницький інтерфейс доступу до периферії комп'ютера, це число присутнє поряд з іншим, що також стосується драйвера, - молодшим номером (minor number). Молодший номер інтерпретується самим драйвером (наприклад, для клонів, він задає старше число пристрою, яке потрібно "розмножити"). Іншим прикладом використання молодших номерів може бути драйвер диска. У той час як доступ до будь-якого розділу диска здійснюється одним і тим же драйвером і, відповідно, через один і той же старший номер, молодший номер вказує, до якого розділу потрібно забезпечити доступ.

Доступ до драйвера здійснюється ядром через спеціальну структуру даних (комутатор пристроїв), кожен елемент якої містить покажчики відповідні функції драйвера - точки входу. Старше число, по суті, є вказівником елемент комутатора пристроїв, забезпечуючи, тим самим, ядру можливість виклику необхідної функції зазначеного драйвера. Таким чином комутатор пристроїв визначає базовий інтерфейс драйвера пристроїв.

Цей інтерфейс різний для блокових та символьних пристроїв. Ядро містить комутатори двох типів пристроїв: bdevsw для блокових і cdevsw для символьних пристроїв. Ядро розміщує окремий масив для кожного типу комутатора і будь-який драйвер пристрою має запис у відповідному масиві. Якщо драйвер забезпечує як блоковий, так і символьний інтерфейс, його точки входу будуть представлені в обох масивах.

Типовий опис цих двох масивів має такий вигляд (призначення різних точок входу ми розглянемо далі у цьому розділі):

struct bdevsw ( int (*d open)(); int (*d_close) () ; int (*d_strategy)(); int (*d_size) (); int (*d_xhalt) () ;

struct cdevsw (

int (*d_open) ();

int (*d^_close) ();

int (*d_read)<) ;

int (*d_write) ()

int (*d_ioctl) ()

int (*d_xpoll) ()

int (*d_xhalt) ()

struct streamtab *d_str;

) cdevsw; Ядро викликає функцію open() необхідного драйвера так:

(* bdevsw.d_open) (dev, ...);

передаючи їй як один з параметрів змінну dev (типу dev t), що містить старший і молодший номери. Макрос getmajor() служить для отримання старшого номера зі змінної dev. Завдяки цьому драйвер може визначити, з яким молодшим номером була викликана функція open (), і виконати відповідні дії.

Комутатор визначає абстрактний інтерфейс драйвера пристрою. Кожен драйвер забезпечує функцію цього інтерфейсу. Якщо драйвер не підтримує будь-які функції стандартного інтерфейсу, він замінює відповідні точки входу спеціальними заглушками, що надаються ядром. Коли ядру потрібно запитати будь-яку операцію драйвера пристрою, воно визначає елемент комутатора, відповідний даному драйверу (використовуючи його старший номер), і викликає необхідну функцію.

У назвах точок входу драйвера використовуються певні угоди. Оскільки в ядрі системи одночасно присутня велика кількість різних драйверів, кожен з них повинен мати унікальне ім'я, щоб уникнути проблем при компіляції (точніше, при редагуванні зв'язків) ядра. Кожен драйвер має унікальне двосимвольне позначення, що використовується як префікс назв функцій. Наприклад, драйвер віртуальної пам'яті ядра /dev/kmem має префікс mm, таким чином функції цього драйвера будуть мати назви mmopen(), mmclose(),mmread() та mmwrite().

У табл. 5.1 наведено деякі точки входу, спільні для різних типів драйверів, а символами хх, з яких починається ім'я кожної функції, є унікальним префіксом драйвера. Стандартні точки входу драйвера відрізняються для різних версій UNIX. Наприклад, деякі версії мають розширений комутатор блокових пристроїв, що включає такі функції, як xxioctl(), xxread() та xxwrite(). У деяких версіях включені точки входу для ініціалізації та скидання шини даних.

Таблиця 5.1. Типові точки входу до драйвера пристрою

Точка входу	Сім-вільний		Низького рівня	Призначення
	Викликається при кожній опера- ції відкриття пристрою. Забезпечує необхідну реініціалізацію фізичного пристрою та внутрішніх даних драйвера. Наприклад, для кожного подальшого відкриття драйвера можуть розміщуватися додаткові буфери, які забезпечують можливість незалежної роботи з пристроєм кільком процесам
	Викликається, коли кількість посилань на цей драйвер стає рівним нулю, тобто жоден із процесів системи не працює з пристроєм (не має відкритим відповідний файл пристрою). Може викликати вимкнення фізичного пристрою. Наприклад, драйвер накопичувача на магнітній стрічці може перемотати стрічку на початок
	Читає дані від пристрою
	Є спільним інтерфейсом управління пристроєм. Драйвер може визначити набір команд, які можуть бути передані йому, наприклад, за допомогою системного виклику
	Викликається під час вступу переривання, пов'язаного з цим пристроєм. Може виконати копіювання даних від пристрою проміжні буфери, які потім зчитуються функцією xxread () на запит прикладного процесу.
	Опитує пристрій. Зазвичай використовується для пристроїв, які не підтримують переривання, наприклад для визначення надходження даних для читання
	Викликається для зупинки драй- віра під час зупинки системи або під час вивантаження драйвера.
	Загальна точка входу для операцій блокового введення/виводу. Назва функції говорить про те, що пристрій може забезпечувати власну стратегію обробки запитів, що надходять, наприклад, змінювати їх порядок для підвищення продуктивності вводу/виводу. Якщо пристрій зайнятий, функція містить запити в чергу. У цьому випадку фактичне введення/виведення ініціює функцію обробки переривання, яка викликається, коли пристрій закінчить попередню операцію введення/виводу

Ядро викликає ті чи інші функції драйвера, залежно від запиту. Наприклад, якщо процес виконує системний виклик read(2) для спеціального файлу символьного пристрою, ядро ​​викличе функцію xxread() для відповідного драйвера символу. Якщо процес запитує ту ж операцію для звичайного дискового файлу, ядро ​​викличе процедуру xxstrategy() для блочного драйвера, що обслуговує цю файлову систему.

Взагалі кажучи, можна виділити п'ять основних випадків, у яких ядро ​​звертається до функцій драйвера:

Про Автоконфігурація. Зазвичай відбувається в процесі ініціалізації UNIX, коли ядро ​​визначає які пристрої доступні в системі.

Про Введення/виведення. Запит на операцію введення/виведення може бути ініційований як прикладним процесом, так і деякими підсистемами ядра, наприклад, підсистемою управління пам'яттю.

Про Обробка переривань. Ядро викликає відповідну функцію драйвера для обробки переривання, що надійшов від пристрою (якщо пристрій здатний генерувати переривання).

Спеціальні запити. Ядро викликає відповідну функцію драйвера обробки спеціальних команд, отриманих з допомогою системного виклику ioctl(2).

П Реініціалізація/Зупин. Деякі типи апаратних архітектур можуть вимагати скидання та реініціалізації пристрою. Певні функції драйвера також викликаються під час зупинення операційної системи.

На рис. 5.2 та 5.3 наведено схеми доступу до драйверів символьного та блокового пристроїв.

Як видно з малюнків, схема обробки запиту ядром UNIX різна для символьних та блокових пристроїв.

При обговоренні точок входу драйверів пристроїв слід мати на увазі, що більшість функцій драйвера, що відповідають за передачу даних, копіюють інформацію з адресного простору ядра, в якому знаходиться сам драйвер, в адресний простір завдання. Коли ядро ​​викликає функцію драйвера, всі дії виконуються у системному контексті процесу. Однак схема виклику функцій може бути різною:

П Функція може бути викликана на запит процесу. Наприклад, якщо процес виконує системний виклик read(2), ядро ​​викликає відповідну точку входу драйвера xxread(), що забезпечує роботу з файлом. І тут кажуть, що функція має контекст завдання.

П Функція може бути викликана іншою підсистемою ядра операційної системи. Наприклад, для блокового драйвера функція xxstrategy () може бути викликана сторінковим демоном, для збереження сторінок у вторинній пам'яті (як правило, на жорсткому диску). Оскільки сторінковий демон є системним процесом, що виконується тільки в контексті ядра, функція xxstrategy () у цьому випадку має системний контекст.

Якщо функція викликається у процесі обробки переривання, вона має контекст переривання -- спеціальний вид системного контексту. Функції драйвера, що відповідають за обробку переривання, наприклад xxintr(), мають цей тип контексту.

Мал. 5.3.

Відмінності в контексті та причинах виклику тих чи інших функцій драйвера дозволяють представити драйвер пристрою, що складається з двох частин: верхньої частини (top half) і нижньої частини (bottom half). Функції верхньої частини драйвера мають синхронний характер, тобто викликаються за певними запитами прикладного процесу та виконуються у його контексті. Таким чином, для цих функцій є адресний простір і u-area процесу, і при необхідності ці функції можуть перевести процес у стан сну (викликом функції sleep() ядра). Функції введення/виведення та керування належать до верхньої частини драйвера.

Виклик функцій нижньої частини має асинхронний характер. Наприклад, не можна передбачити момент виклику функції обробки переривань, і ядро ​​не може контролювати, коли ця функція буде викликана. Виконання таких функцій відбувається у контексті ядра і зазвичай немає ніякого відношення до контексту поточного процесу. Таким чином, функції системного контексту не мають права адресувати структури даних поточного процесу, наприклад, його u-area, а також не можуть перевести процес у стан сну, оскільки це заблокує процес, що не має безпосереднього відношення до роботи драйвера.

Дві частини драйвера потребують синхронізації. Наприклад, у випадку, коли функції обох частин використовують одну і ту ж структуру даних, функція верхньої частини при виконанні повинна заблокувати переривання на період роботи з "областю пам'яті, що розділяється". В іншому випадку переривання може надійти в той момент, коли цілісність структури даних порушена, що призведе до непередбачуваних результатів.

Всі представлені вище функції, за винятком xxhalt(), xxpoll() та xxintr(), належать верхній частині драйвера. Функція xxhalt() викликається ядром при зупинці системи і, таким чином, має системний контекст, не пов'язаний із контекстом прикладного процесу.

Функція xxpoll () зазвичай викликається при обробці ядром переривання таймера для всіх пристроїв, вказаних як опитувані. Це необхідно, зокрема, для пристроїв, які не можуть або не хочуть використовувати апаратні переривання. Натомість xxpoll () може використовуватися для емуляції переривань, наприклад викликаючи функцію xxintr () на кожен n-ний тик системного таймера. Тому і функція xxpoll() та функція обробки переривання xxintr() не можуть розраховувати на контекст прикладного процесу. У більшості версій UNIX функції опитування та обробки переривань викликаються не через комутатор пристроїв, а через спеціальні таблиці ядра.

У UNIX SVR4 визначено дві додаткові точки входу - init() та start(). Драйвер реєструє ці функції у таблицях ядра io init та io_start. Код початкового завантаження системи запускає функції xxinit() перед ініціалізацією ядра, а функції xxstart() відразу після ініціалізації.

17.02.2017

Напевно кожен, хто встановлював операційну систему, потрапляв у незручну ситуацію, коли потрібно встановити драйвера для відеокарти, а її модель невідома. Або просто необхідно оновити драйвера на відеокарті, не знаючи її назви. Зазвичай у таких ситуаціях користуються настановним диском, який обов'язково продається з відеокартою. Але що робити, якщо з якихось причин такий диск відсутній?

Для стабільної роботи відеокарти необхідно не просто встановити для неї драйвера, а регулярно оновлювати їх, коли з'являються нові версії. Тим більше що версія драйвера іноді впливає на продуктивність відеокарти. Давайте розберемося, як дізнатися модель відеокарти і де скачати найновіші драйвера для неї.

На жаль, визначити модель відеокарти онлайн неможливо. Для визначення скористайтесь спеціальними програмами.

Як дізнатися модель відеокарти

Є кілька способів дізнатись точно, яка саме відеокарта у вас встановлена.

Спосіб 1: Дізнаємося модель відеокарти за допомогою ідентифікатора обладнання

1. На робочому столі на значку "Мій комп'ютер" («Цей комп'ютер»в Windows 10) клацаємо правою кнопкою миші і в вікні вибираємо пункт «Властивості».



2. У вікні знаходимо рядок "Диспетчер пристроїв"та натискаємо на неї.



3. Далі необхідно відкрити гілку з розділом «Відеоадаптери». У ній буде відображено відеокарти, підключені до комп'ютера. Якщо раніше драйвера вже були встановлені, ви побачите повну назву і модель відеокарт.



4. Це може бути достатньо, якщо ви бажаєте просто оновити вже встановлені драйвера. Якщо ж драйвера зовсім відсутні, то швидше за все ви побачите у списку відеоадаптерів рядок "Стандартний VGA графічний адаптер"або .



5. Натискаємо по такій невідомій відеокарті правою кнопкою миші і в меню вибираємо пункт «Властивості».



6. У списку закладок зверху знаходимо «Відомості»та переходимо туди.
7. Під написом «Властивість»ви побачите меню, що випадає, за яким необхідно натиснути. Шукаємо рядок «ІД обладнання».



8. В полі «Значення», що знаходиться нижче, ви побачите кілька рядків. Необхідно виділити останню, натиснути на ній праву кнопку миші та вибрати в меню пункт «Копіювати».



9. Після того, як ВД буде скопійовано, переходимо на наступний сайт
10. Перейшовши на посилання, ви побачите пошукове поле вгорі сайту. Сюди необхідно вставити раніше скопійовану інформацію про ВД обладнання. Далі потрібно натиснути кнопку "Шукати", розташовану правіше за рядок пошуку.



11. Якщо все було зроблено правильно, то як результат ви побачите модель відеокарти і зможете навіть завантажити відразу драйвер до неї. Але повернемося до пошуку драйверів трохи згодом.

Спосіб 2: Дізнаємося модель відеокарти за допомогою засобу діагностики DirectX

Якщо з якихось причин згаданий сайт не працює, завжди отримайте інформацію про графічний чіп стандартними засобами Windows.

Спосіб 3: Дізнаємося модель відеокарти за допомогою засобу «Відомості про систему»

Як завантажити драйвер відеокарти

Після того, як вдалося дізнатися про модель відеокарти, потрібно встановити або оновити драйвер для неї. І тому є кілька способів.

Спосіб 1: Викачуємо драйвер з порталу devid.info

Як вже згадувалося вище, після визначення відеокарти з ІД на порталі devid.info/ru є одразу можливість качати необхідні драйвера.

Спосіб 2: Завантажуємо драйвер з офіційного сайту

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

1. Для цього слід вибрати сайт виробника вашої відеокарти, перейшовши за наступними посиланнями
2. У відповідних полях вам необхідно буде лише вказати тип вашого пристрою, серію, модель та операційну систему. Часто ці параметри можна визначити автоматично.
3. Натискаєте кнопку «Пошук»і на сторінці, що завантажувалася драйвер.

Ось як це виглядає процес пошуку драйвера для відеокарт NVidia

У будь-якому випадку, після того, як потрібний драйвер буде закачано, вам залишиться лише запустити програму установки і почекати поки вона закінчить свою операцію установки або переустановки. Щоб уникнути проблем у майбутньому, ви можете створити окремий диск або флеш-накопичувач з необхідними системними програмами. Особливо це стане в нагоді в умовах відсутності інтернету, що теж трапляється не рідко.

Якщо ви самостійно збирали свій комп'ютер, купуючи для нього комплектуючі окремо, то в такому випадку всі драйвера для комп'ютера вже не знайти на одному єдиному сайті виробника, як це легко було б зробити при покупці готового комп'ютера (про це розповідається в статті «Як знайти драйвера, якщо було куплено ноутбук чи готовий стаціонарний комп'ютер!»). Адже ви купували не готовий комп'ютер, який належав би якомусь виробнику, мав би свою модель та драйвера для якого можна було завантажити з одного сайту. Якщо комп'ютер зібраний із самостійно обраних вами запчастин, значить він уже не буде відповідати якійсь моделі і належати якомусь виробнику, тому що це вже ваш витвір:) Тому драйвера доведеться шукати окремо для всіх пристроїв, з яких було зібрано комп'ютер. Сюди ж можна віднести той випадок, коли після покупки готового (вже зібраного) комп'ютера ви за якийсь час вирішили замінити якісь «залізяки».

Зараз я покажу, як знайти всі потрібні драйвера для самостійно налаштованого комп'ютера вручну, через інтернет.

Про те, що таке драйвера розказано у статті:

Отже, ви самі підібрали всі комплектуючі, зібрали комп'ютер, встановили Windows і бачите, що драйвера встановлені не для всіх пристроїв, а може навіть не встановлені практично ні для яких. Про те, чи встановлені всі драйвера, можна дізнатися зі стандартної утиліти «Диспетчер пристроїв». Як це зробити я розповідав в окремій статті.

І щоб встановити драйвера у цьому випадку є кілька варіантів.

Зверніть увагу!
Якщо у вас не встановилися автоматично навіть драйвера на мережні карти, що не дає вам можливості вийти з цього комп'ютера в інтернет, то нижче дії, що розглядаються, доведеться виробляти з будь-якого іншого комп'ютера, де є вихід в інтернет. А після того, як драйвера все завантажуєте, потрібно буде перенести їх на потрібний комп'ютер, наприклад, через флешку або диск.

Варіант №1. Пошук драйверів вручну за кодом пристроїв через сайт devid.drp.su

Цей варіант я вважаю найоптимальнішим. Спосіб є визначення коду пристрою і пошук драйверів в інтернеті за цим кодом на різних сайтах.

Припустимо, що в диспетчері пристроїв ми бачимо приблизно таку картину:

Тобто. на комп'ютер не інстальовано драйвер для кількох пристроїв. Однак визначити через диспетчер пристроїв, для яких пристроїв немає драйверів проблематично, тому що в назвах якось все розмито. Можна лише приблизно зрозуміти. Наприклад, "Ethernet-контролер" - це швидше за все мережева карта для підключення дротового інтернету. «Мережевий контролер» — це, мабуть Wi-Fi адаптер, тобто. мережна карта для доступу до Інтернету через Wi-Fi.

Але кожен пристрій має свій унікальний номер, який диспетчер пристроїв якраз може нам показати. А дізнавшись номер, ми зможемо знайти драйвер для пристрою через Інтернет.

Розглянемо кілька прикладів, як знайти драйвера вручну за кодом пристроїв:

На початку я знайду драйвер для незрозумілого пристрою PCI-контролер Simple Communications.

Визначаємо код пристрою, для якого хочемо знайти драйвер.

Щоб визначити код пристрою, клацаємо по ньому в диспетчері пристроїв правою кнопкою миші і з меню вибираємо «Властивості»:

У вікні виберіть вкладку «Відомості», а потім нижче, під написом «Властивості», виберіть «ІД обладнання»:

В першу чергу пробуємо шукати за кодом з найнижчого (4-го) рядка. Клацніть правою кнопкою нижче по 4-му рядку з кодом і оберіть «Копіювати».

Пробуємо знайти драйвер за кодом на сайті devid.drp.su.

Після того, як скопіювали код, відкриваємо сайт:

Devid.drp.su

Спробуймо знайти драйвер на ньому. Цей сайт відноситься до програми DriverPack Solution, яка збирає практично всі можливі драйвера. Тут з великою ймовірністю можна знайти драйвер для будь-якого пристрою.

Відкривши сайт, перше, що вам потрібно зробити - вставити в самий верхній рядок скопійований на попередньому кроці код пристрою і видалити в цьому коді все що йде від символу & до кінця.

Наприклад, ви копіювали код:
PCI\VEN_8086&DEV_0166 &CC_0300

Отже, після видалення символів від «&» у вас повинен залишитися код:
PCI\VEN_8086&DEV_0166

Якщо ви не знаєте, яка у вас система, то відкрийте пошук Windows і введіть там «Відомості про систему», після чого виберіть програму зі списку:

У програмі, що відкрилася, у вікні зліва, виберіть «Відомості про систему» ​​і праворуч у рядку «Ім'я ОС» з'явиться версія вашої Windows (у моєму прикладі на зображенні нижче «Windows 10»), а в рядку «Тип» — розрядність: x64 або x86:

На основі цих даних і вказуємо тип та розрядність системи на сайті devid.drp.su.

Після того, як код пристрою вказано і версія Windows вибрано, натискаємо кнопку "Search Drivers".

В результаті на сторінці з'явиться список драйверів, що підходять за вказаним кодом обладнання та для вашої версії Windows. За допомогою кнопки «Завантажити» завантажуємо один із драйверів на комп'ютер.

Зверніть увагу!
Якщо відображається декілька однакових драйверів (як на зображенні вище), завантажуйте драйвер, у якого найсвіжіша дата випуску в колонці «Версія драйвера».

Клікнувши по кнопці «Завантажити», драйвер завантажиться на ваш комп'ютер і залишиться лише встановити. В установці драйверів немає взагалі нічого складного і цей момент я торкнувся в окремій статті.

Зверніть увагу!

Буває, що у списку драйверів відображатимуться різні драйвери, наприклад:

Це означає, що код обладнання може бути схожим на кілька пристроїв. У такому випадку ви можете просто завантажувати і пробувати встановлювати всі варіанти, що пропонуються до тих пір, поки не встановиться потрібний драйвер.

Як бачимо, драйвер було знайти неважко. Зараз розгляну ще один приклад, щоб стало зрозуміліше:) Знайду для прикладу драйвер для пристрою, який в диспетчері пристроїв позначається як «Ethernet-контролер».

Клікаю правою кнопкою миші, відкриваю властивості:

У вікні вибираю вкладку «Відомості», зі списку вибираю пункт «ІД обладнання» та копіюю код із 4-го рядка:

Відкриваю сайт devid.drp.su, вказую там скопійований номер, видаляю все, починаючи від символу «&». Далі вибираю версію Windows та виконую пошук:

Для мого пристрою та обраної мною версії Windows відобразилася лише одна версія драйвера, яку я можу завантажити та інсталювати:

От і все!

Однак, все ж таки зрідка буває таке, що на сайті devid.drp.su не знайдеться драйверів за вказаним вами кодом обладнання. У такому разі є альтернативний варіант, який розглянемо нижче.

Альтернативний варіант пошуку драйверів за кодом пристрою

Якщо драйверів на відомому сайті devid.drp.su для потрібного вам пристрою не знайшлося, то можна застосувати такий простий спосіб:

Визначаємо код пристрою. Так само копіюємо код обладнання (4-ю) строчку:

Шукаємо драйвер на різних сайтах.

Тепер йдемо на сайт Google.com і прямо в пошуковий рядок вставляємо скопійований код, після чого видаляємо з коду символ «&» і все, що слідує після нього, наприклад:

PCI\VEN_8086&DEV_1C3A &СС_0780= PCI\VEN_8086&DEV_1C3A

Натискаємо кнопку пошуку та перед нами відображається список сайтів, що підходять під наш запит:

Тепер потрібно відкривати сайти по черзі, починаючи з першого (верхнього) і дивитися, чи можна на сайті завантажити драйвера.

Відразу варто відзначити, що не на всіх сайтах ви знайдете потрібний драйвер, оскільки на деяких з них не буде драйвера для вашої версії Windows, а на деяких взагалі всяка лабуда замість драйверів.

На прикладі зображенні вище я обвів ті сайти, на яких драйвера дійсно найчастіше можна знайти і без проблем скачати. Ось ці сайти:

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

А тепер розглянемо кілька прикладів завантаження драйверів з різних сайтів.

Приклад завантаження драйвера з сайту driver.ru:

Коли ви потрапите на сайт з результатів пошуку, на сторінці вже будуть відображатися драйвера, більшість з яких сумісна з вашим пристроєм.

Тут ви можете просто завантажувати по черзі всі драйвера, які відобразив сайт і намагатися встановлювати доти, доки потрібний драйвер не встановиться. Всі несумісні драйвера або не встановляться, або просто не працюватимуть, тому встановити щось не можна не боятися.

Не забудьте звертати увагу на версію Windows, для якої призначено драйвер.

Майте на увазі!
Драйвера для Windows 8, Windows 8.1 і Windows 10 дуже часто сумісні і, якщо ви, наприклад, не змогли знайти драйвера конкретно для Windows 8.1, спробуйте встановити драйвера для Windows 8. Або якщо не змогли знайти драйвера для Windows 10, спробуйте встановити від Windows 8.1 або Windows 8. Буває також, що драйвери для Windows 7 сумісні з Windows 8, 8.1 і Windows 10. Тобто. можна намагатися встановлювати драйвера від різних систем.

Розглянемо приклад процесу завантаження з цього сайту. Знайшовши потрібний драйвер, клацаємо по кнопці завантаження внизу:

У наступному вікні потрібно підтвердити, що ви не робот, поставивши галочку в зазначеному місці (див. зображення нижче). Потім натисніть унизу кнопку «Завантажити»:

І нарешті, на черговій сторінці побачимо в самому верху посилання на завантаження у вигляді назви файлу з розширенням:

Клацаємо по ній і завантажуємо файл.

Приклад завантаження драйвера з сайту members.driverguide.com:

Перейшовши на сайт із пошукової системи, на сторінці з'явиться список ймовірно сумісних драйверів з вашим пристроєм:

Клікнувши по кнопці завантаження відкриється нова сторінка, де в очі впадає велика кількість реклами.

Увага!
Не клікайте куди потрапило якщо на сайті багато реклами, будьте уважні, інакше можна підчепити віруси та іншу заразу на комп'ютер!

У наступному вікні в центрі з'явиться віконце для підтвердження того, що ви реальна людина, а не програма:) Вам потрібно дочекатися завантаження вмісту вікна і натиснути кнопку «Показати»:

Відкриється нове вікно, де знову кілька секунд очікуємо на завантаження вмісту. У вікні з'явиться код поруч із написом: "Введіть". Цей код потрібно переписати в точності як рядок нижче ("Your Answer") і натиснути "Return to Page":

Вас поверне на початкову сторінку, де тепер з'явиться кнопка «Continue». Натиснувши почнеться завантаження драйвера на комп'ютер:

Ось таким альтернативним способом можна спробувати знайти вручну драйвера за кодом пристроїв. Звичайно для цього варіанту я показав на прикладах завантаження драйвера тільки з 2-х сайтів, а їх величезна кількість. Але принцип завантаження на всіх сайтах однаковий. Відрізняється лише здебільшого інтерфейс і іноді порядок скачування.

Але я більше схиляюся, що ви зможете легко знайти драйвера і за основним методом, запропонованим у варіанті №1.

Варіант №2. Пошук драйверів на офіційних сайтах виробників пристроїв

Якщо у вас не вдалося знайти драйвера для ваших пристроїв за одним варіантом, то це можна зробити ще ось таким способом.

Вам потрібно буде подивитися виробника та модель кожного пристрою в комп'ютері через документацію до них або спеціальні програми (наприклад, Aida64 або Sysinfo Detector), після чого окремо шукати драйвера для кожного пристрою через офіційний сайт виробника або (якщо на офіційному сайті драйвером немає) в інтернеті за моделлю пристрою.

Візьмемо такий приклад. У диспетчері пристроїв у мене видно, що не встановлений у системі драйвер на відеокарту і ще якийсь незрозумілий пристрій:

Як визначив, що на відеокарту? А тому що якщо у списку пристроїв у розділі "Відеоадаптери" є пристрій "Стандартний VGA графічний адаптер", значить немає драйвера на відеокарту, інакше пристрій мав би назву вашої відеокарти, наприклад "NVIDIA GeForce GTX980".

Давайте розглянемо послідовність ваших дій:

Дізнаємося виробника та модель пристрою.

Зверніть увагу!
Якщо у диспетчері пристроїв у вас є «Невідомий пристрій», то ймовірно не встановлений драйвер для якогось пристрою материнської плати або спеціальна програма для материнської плати. Отже, потрібно спочатку встановити всі драйвери для вашої материнської плати та програми для неї.

Якщо ви збирали комп'ютер з окремих комплектуючих, то у вас могли залишитися документи щодо кожного придбаного пристрою, де вказано те, що нам потрібно - виробник і модель. Якщо документації ніякої не залишилося, дізнатися модель допоможе одна з програм, що визначають залізо вашого комп'ютера. Я рекомендую Aida64 або Sysinfo Detector. Перша – платна, але їсти ви можете скористатися нею безкоштовно протягом 30 днів. А друга має повністю безкоштовну редакцію. Якщо думаєте, що вибрати, то вибирайте тимчасово – Aida64, оскільки якість у цієї програми все-таки буде вищою.

Як встановлювати та користуватися програмою Aida64 розказано у статті:

Як встановлювати та користуватися Sysinfo Detector розказано у статті:

Якщо ви визначаєте пристрої через програму Aida64то визначити, що за пристрої без драйверів можна, вибравши зліва розділ «Пристрої > Пристрої Windows», а потім праворуч відкрити категорію «Unknown» (невідомі). Внизу з'явиться інформація про вибраний пристрій:

Отже, у моєму прикладі невідомий пристрій має назву Asus ATK-110 ACPI Utility.

Вище я згадував, що невідомий пристрій – це, швидше за все, щось на материнській платі, тому визначимо відразу, яка материнська плата в пристрої. Для цього відкриваємо розділ «Системна плата» та переходимо до такого ж підрозділу. Праворуч у вікні побачимо виробника та модель системної плати: Asus P5KPL-AM EPU.

Тепер розберемося із відеокартою. Відеокарта, як правило, правильно визначається в Aida64 через розділ "Відображення" > "Відео PCI/AGP". Як бачимо, програма визначила відеокарту: nVIDIA GeForce GT 430»:

Якщо ви дивитеся пристрої через Sysinfo Detector, то побачити пристрої з невстановленими драйверами можна двома способами. Перший — у розділі «Відхилення»:

Як бачимо, виявлено той самий пристрій, що і через програму Aida64: ACPI/ATK0110

І другий спосіб - у розділі "PCI-пристрою" вибрати підрозділ "Невідомі пристрої". Тут програма побачила одразу 3 «проблемні» пристрої та один з них, якраз материнська плата: Asus P5KPL-AM EPU.

Виробника та модель відеокарти краще подивитися у розділі «PCI-прилади». У списку знайдіть підрозділ «Display controller»:

З прикладу видно, що виробник картки NVIDIA, а модель GeForce GT 430.

Отже, потрібні дані дізналися і тепер шукатимемо драйвер.

Шукаємо драйвер на сайтах-виробниках пристроїв.

З'ясували, що не вистачає драйвера, швидше за все, для якогось пристрою на материнській платі, а може бути якоїсь програми спеціально для материнської плати. Виробник плати – Asus, а модель у прикладі P5KPL-AM EPU. Якщо виробник Asus, то будемо шукати на сайті офіційному сайті Asus.

Про те як шукати офіційний сайт виробника пристрою та завантажувати з нього драйвера докладно описано. Якщо коротко, вам потрібно відкрити пошукову систему Google, набрати там назву виробника та відкрити перший сайт у результатах пошуку. Далі слід перейти до розділу «Сервіс» або «Підтримка» та вказати модель пристрою, наприклад:

Крім драйверів, звертайте увагу і на розділ «Утиліти» (його видно у списку на зображенні вище), тому що іноді «Нерозпізнаний пристрій» — це якась не встановлена ​​спеціальна програма для материнської плати. Краще встановити весь комплект для материнської плати, представлений на сайті, щоб перевірити, чи була проблема.

У цьому прикладі продемонстровано пошук драйверів для материнської плати. Якщо встановити всі драйвери та утиліти для неї, то "Невідомий пристрій" з диспетчера пристроїв має зникнути.

Знайдемо драйвер для відеокарти. Судячи з даних, взятих із програм Aida64 і Sysinfo Detector, виробник відеокарти – NVIDIA, а модель GeForce GT 430. Якщо виробник NVIDIA, значить шукаємо офіційний сайт цієї компанії точно також через Google:

На сайті відразу бачимо розділ «Драйвери» та в ньому пункт «Завантажити драйвери». Відкриваємо:

Відкриється вікно, де потрібно вказати дані про відеокарту. Тип продукту в моєму прикладі GeForce, якщо модель GeForce GT 430, то серія продуктів підходить GeForce 400 Series. Тут не складно зорієнтуватись. Далі у списку «Сімейство товарів» вибираємо вже саме модель – «GeForce GT 430». І залишилося вибрати тільки версію Windows, встановлену на вашому комп'ютері та мову драйвера. Потім натискаємо «Пошук»:

Відкриється сторінка для завантаження потрібного драйвера. Натискаємо кнопку «Завантажити зараз»:

На наступній сторінці приймаємо умови угоди та натискаємо кнопку «Прийняти та завантажити»:

У такий же спосіб ви можете завантажити драйвер, в принципі, для будь-якого пристрою, знаючи його виробника та модель. Потрібно лише знайти офіційний сайт виробника і вказати там модель.

У крайньому випадку, якщо, наприклад, не вдається знайти драйвера на офіційному сайті, ви можете пошукати їх на інших сайтах, вказавши в пошуку GoogleПриміром такий запит: «драйвер для Asus P5KPL-AM EPU». Замість Asus P5KPL-AM EPU вам відповідно потрібно вказати виробника і модель саме вашого пристрою, для якого шукайте драйвера.

Ну і на закінчення відзначу, що якщо ви користуєтеся Windows 8 і старше, то проблем з драйверами швидше за все у вас не буде. Ці системи встановлюють у більшості випадків всі драйвери автоматично відразу після інсталяції Windows. Пробував на кількох ноутбуках перевстановити Windows 8.1 і Windows 10 і на кожен були встановлені автоматично всі драйвери, внаслідок чого відпала потреба шукати їх самому.

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

Також можна автоматично встановити драйвера на комп'ютер за допомогою спеціальних програм. Про таку можливість розказано в окремій статті:

Усього Вам доброго! До зустрічі в інших статтях:)

Як ми знаємо, на апаратному рівні сучасний комп'ютер складається з функціональних вузлів, що становлять ті чи інші електронні компоненти. Широкому колу користувачів персональних комп'ютерівзнайомі такі функціональні блоки як: процесор, пам'ять, відеокарта, звукова карта, жорсткий диск, контролер вводу-виводу (що забезпечує роботу клавіатури, миші, джойстика, USB-носіїв (флешок)), принтер, сканер та деякі інші. на фізичному рівнідані пристрої взаємодіють між собою у вигляді спеціальних шин і протоколів, створюючи сукупністю своєї взаємодії симбіоз операцій, який, у випадку, характеризує функціонування комп'ютера. Але хіба комп'ютер є лише набір електронних компонентів? Звичайно ж ні, адже один з основних апаратних модулів, центральний процесор, спроектований для виконання машинних інструкцій, із послідовностей яких, як ми знаємо, складаються програми, у світлі цього було б доречно згадати ще один рівень - програмний. Тепер давайте повернемося в не стільки далеке минуле; на зорі комп'ютерної ери код програм (які часто писалися безпосередньо в машинних кодах / низькорівневих мовах) міг легко взаємодіяти з апаратурою безпосередньо, оскільки апаратна архітектура була відносно простою. Однак з часом технології розвивалися, апаратний і програмний рівні еволюціонували взаємопов'язано, і перший прийшов до появи великої різноманітності пристроїв, а другий до появи величезної різноманітності програмних модулів, що зумовили, надалі, появу операційних систем. Операційна система стала ключовою віхою в історії розвитку комп'ютерної індустрії, оскільки саме вона, серед іншого, виконувала роль сполучної ланки, своєрідного координатора (диспетчера), що забезпечив взаємодію між пристроями та програмами: приймала запити від програмного шару (наприклад, програм користувача) на обмін даними з тим чи іншим пристроєм і навпаки, тобто фактично виконувала роль поєднання апаратної і програмної частинами. Операційні системи теж стояли дома, і якщо спочатку взаємодія операційної системи з апаратурою комп'ютера було відносно простим, то в міру ускладнення архітектури та запровадження нових апаратних можливостей, ускладнювалася і структура операційної системи. Протягом усього часу розвитку операційних систем розробники намагалися створити код, що забезпечує повноцінну взаємодію з максимально можливою кількістю наявних на ринку апаратних пристроїв. Тим не менш, подібний підхід, у міру ускладнення архітектури персональних комп'ютерів x86, призвів до появи концепції відокремленого програмного шару, що має назву драйвер, відповідального за взаємодію з тим чи іншим класом/типом пристроїв. Концепція драйвера виявилася настільки вдалою, що, крім основного напряму - підтримки фізичних пристроїв, була екстраполована і на деякі категорії логічних/віртуальних пристроїв. У цій статті ми розповідатимемо про те, що ж собою представляє драйвер Windows.

Теорія

Давайте трохи відійдемо від концепції драйвера та розглянемо загальну теорію. Для того, щоб зрозуміти що ж є драйвером в системі, спочатку необхідно пройти мінімум теорії із загальної архітектури x86-64. Чому x86, та тому що саме ця платформа: а) обрана мною для експериментів; б) є найбільш поширеною в клієнтському сегменті операційних систем Windows. Озвучені у цьому розділі особливості дадуть нам розуміння багатьох аспектів роботи як безпосередньо операційної системи, і, відповідно, драйверів у її складі.

Режими роботи процесора

Внутрішня структура будь-якої операційної системи базується на апаратних особливостях платформи, де вона працює. Центральною ланкою є процесор, процесори архітектури x86-64 мають кілька режимів роботи:

• Реальний режим (Real mode);
• Віртуальний режим (Virtual mode);
• Захищений режим (Protected mode);
• Довгий режим (Long mode).

На зорі ери розвитку персональних комп'ютерів архітектури x86 процесор працював у реальному режимі. Тим не менш, реальний режим поступово пішов у минуле, оскільки мав ряд особливостей, що унеможливлюють подальший розвиток технологій: 16-бітну шину даних і 20-бітну шину адреси (обмеження за адресацією), сегментну адресацію з розмірами сегментів у 64 кілобайти (незручність використання адресного простору), відсутність розмежування доступу до адресного простору. З метою зняття існуючих обмежень було розроблено захищений режим, який надавав ряд важливих для розвитку операційних систем особливостей: "багатозадачність", механізм захисту (доступ до привілейованих команд), що забезпечує контроль доступу різних ділянок коду (програм) один до одного, модель віртуальної пам'яті. У захищеному режимі процесорів Intelархітектури x86 реалізовані так звані кільця захисту чи рівні привілеїв. Усього їх чотири: 0 (найбільш привілейований), 1, 2 та 3 (найменше привілейований). Рівні привілеїв покликані захистити код режиму ядра від програм користувача і програм користувача один від одного, оскільки це може призвести до порушення працездатності. Однак операційна система Windows не використовує всі перераховані рівні, в ній задіяні лише два з них: 0-й та 3-й.
Для наочності розуміння цього наведемо спрощену схему взаємодії компонентів Windows:

Як ви бачите, внутрішнє середовище операційної системи Windows поділено на дві частини і підтримує два режими виконання:

• Режим користувача- непривілейований режим, зіставлений з апаратним третім кільцем захисту процесора;
• Режим ядра - привілейований режим, зіставлений з апаратним кільцем 0-м захисту процесора;

У цій особливості полягає найбільш, мабуть, важливий момент розуміння внутрішньої будови Windows: глобально операційна система як би поділена на дві основні частини: режим користувача і режим ядра.

Це варто зрозуміти, усвідомити і запам'ятати раз і назавжди, оскільки, власне, це одна з базових, основних концепцій багатьох сучасних операційних систем.
Режими користувача та режим ядра мають такі відмінності:

• Ізольованими (не перетинаються) віртуальними адресними просторами: простір режиму користувача займає нижню частину (адреси з по), простір режиму ядра займає верхню (адреси з по);
• Різними привілеями доступу коду до ресурсів (пам'яті, процесору, пристроїв та ін).

У режимі користувача виконуються такі процеси:

Підсистема	Опис
Процеси забезпечення працездатності системи (System Support Processes)	Процес входу до системи Winlogon (winlogon.exe) Процес локального сервераавтентифікації lsass (lsass.exe ) Процес диспетчера управління службами (services.exe) Процес диспетчера сесій (smss.exe) Процес консолі (conhost.exe) Процес диспетчера локальних сесій (lsm.exe) . . .
Процеси служб/сервісів (Service Processes)	Хост-процес для служб (svchost.exe) Процес диспетчера черги друку (spoolsv.exe) Процес управління службою WMI (winmgmt.exe) . . .
Програми (Applications)	Додатки користувача (всі програми, що не входять до інших категорій). Диспетчер завдань (taskmgr.exe) Провідник (explorer.exe) Консоль управління (mmc.exe) . . .
Підсистеми оточення (Environment Subsystems)	Підсистема Win32 (csrss.exe, kernel32.dll, advapi32.dll, user32.dll, gdi32.dll, ...) Підсистема Linux (lxss.sys, lxcore.sys) Підсистема POSIX (psxss.exe, psxrun.exe, posix.exe, psxdll.dll) Підсистема OS/2 (os2.exe, os2ss.exe, os2srv.exe) Підсистема WOW/WOW64 (wow64win.dll, wow64.dll, wow64cpu.dll) . . .
Інтерфейс до функцій ядра	Забезпечує передачу керування в ядро ​​для функцій, яким це необхідно. Підтримується бібліотекою ntdll.dll

У режимі ядра виконуються:

Підсистема	Опис
Виконавча система (Executive)	Диспетчер введення-виводу Диспетчер процесів Диспетчер потоків Диспетчер віртуальної пам'яті Диспетчер об'єктів Диспетчер PnP Диспетчер харчування Диспетчер вікон . . .
Ядро (Kernel)	ініціалізація критичних для системи драйверів етапу завантаження, міжпроцесорна синхронізація, планування та диспетчеризація процесів/потоків/переривань, обробка/диспетчеризація винятків/помилок та деякі інші функції (ntoskrnl.exe, ntkrnlmp.exe, ntkrnlpa.exe, ntkrpamp
Драйвери пристроїв (Device Drivers)	драйвери фізичних/логічних/віртуальних пристроїв: драйвери файлових систем, мережі, дисків та ін.
Віконна/графічна підсистема (Windowing And Graphics System)	Підсистема підтримки вікон та графіки, що забезпечує підтримку графічних функцій інтерфейсу користувача(Graphic User Interface, GUI). (win32k.sys)
Рівень абстрагування обладнання (Hardware Abstraction Layer, HAL)	забезпечує незалежність від апаратної частини платформи, ізолює компоненти ядра специфіки апаратного забезпечення. (hal.dll)

Оскільки будь-яка операційна система просто зобов'язана вміти працювати з апаратними засобами, у дистрибутиві (комплекті установки/системних файлах) присутні драйвери ключових компонентів апаратного забезпечення, без яких система буквально втратить доступ до апаратної частини з усіма проблемами, що випливають з цього: не зможе функціонувати або у всьому пройде процедуру власного встановлення. Подані ці "внутрішні" драйвери у вигляді так званої вбудованої бібліотеки драйверів, що видозмінюється за складом від версії до версії, залежно від етапів еволюціонування апаратного забезпечення та ринкових тенденцій. Драйвера зі складу цієї бібліотеки, при необхідності, встановлюються на етапі інсталяції операційної системи в залежності від виявлення (ідентифікації) у комп'ютері тих чи інших пристроїв. У загальному випадку під час інсталяції код модуля виявлення обладнання виконує визначення встановлених у комп'ютері пристроїв і перевіряє у своїй бібліотеці наявність сумісних драйверів. Для тих пристроїв, для яких є системні драйвера, виконується установка в автоматичному (фоновому) режимі. Тим самим "на виході", після інсталяції операційної системи, ми можемо отримати мінімально-необхідний для функціонування набір системних драйверів, який дозволяє організувати працездатне початкове робоче середовище. Але варто пам'ятати, що обмежуватися вбудованими у дистрибутив драйверами не варто, оскільки для повноцінного функціонування більшості пристроїв можуть знадобитися драйвера, що надаються виробником пристрою.

Залишається відкритим питання: чи справді всі компоненти режиму ядра взаємодіють з обладнанням виключно через рівень HAL? чи є винятки? У Мережі в багатьох джерелах наводяться схеми, на яких драйвера графічного адаптера взаємодіють з відеокартами як би "безпосередньо", в обхід HAL. Наскільки я пам'ятаю, графіці в деяких версіях Windows відводився найвищий пріоритет, тому її було виділено в окрему категорію пристроїв, що працює безпосередньо з графічним адаптером, і зроблено це з метою прискорення графічного інтерфейсусистеми.

Рівні запитів переривань (IRQL)

Серед ключових внутрішніх механізмів, що визначають функціонування операційної системи Windows, є досить важлива для розуміння принципів роботи драйверів тема, яку обійти стороною навряд чи вийде. Механізм цей зветься рівня запитів переривань(Interrupt Request Level, IRQ Level, IRQL) і досить складний для розуміння, тому поглиблене його вивчення виходить далеко за рамки матеріалу, що викладається, проте в даній статті ми спробуємо короткого викладу(Ну а в майбутньому виділимо під нього окрему статтю). Відверто кажучи, сам я досі плутаюсь у концепції IRQL, тому викладатиму власне розуміння планомірно, крок за кроком, з опорою на знання, отримані на кожному з етапів.
Термін переривання завжди асоціювався у мене з реальним режимом роботи процесора, переносячи за часів операційної системи MSDOS, у якій усе було досить просто: існував набір із 256 переривань, доступних через таблицю векторів переривань. Частина цих переривань були апаратними, відповідно генерувалися самостійно по будь-яким зовнішнім апаратурним подіям, інші були програмними, відповідно могли викликатися з коду додатків. Записи в таблиці переривань могли бути перевизначені, тобто вектор обробника переривання був доступний зміни на власний розсуд на власну процедуру обробки. Таких понять, як рівень запитів переривань, не існувало, все було просто і зрозуміло. Однак, з еволюцією процесорів та операційних систем з'явився спочатку захищений режим, а потім уже й Windows, з цього моменту все почало стрімко ускладнюватись.
Буквально раптово, у перших версіях Windows 95/NT, з'явилася якась таблиця (що складається з 32 рівнів запитів переривань), рівні якої градуються від найнижчого 0 (passive) до найвищого 31 (high):

Ім'я	Клас	Призначення	Рівень Intel x86-64
HIGH	Апаратний	Найвищий рівень. Немасковане переривання та інші типи.	31
POWER	Апаратний	Події збою харчування	30
IPI	Апаратний	Міжпроцесорний сигнал. Сигнали міжпроцесорної взаємодії.	29
CLOCK	Апаратний	Такт системного таймера	28
PROFILE	Апаратний	Контроль продуктивності. Таймер профілювання ядра (механізм виміру продуктивності системи).	27
DEVICE	Апаратний	DIRQL (Devices IRQL). Апаратні переривання пристроїв.	3-26
DISPATCH	Програмний	Операції планувальника/відкладені дзвінки процедур (DPC).	2
APC	Програмний	Асинхронні дзвінки процедур.	1
PASSIVE	Програмний	Пасивний рівень. Немає переривань. Звичайний рівень виконання коду режиму користувача	0

Як можна помітити, у наведеній таблиці є дуже цікавою особливістю: разом зведені і програмні та апаратні рівні (0-2 це програмні рівні, а з 3-31 це апаратні).

IRQL – власний програмний атрибут, введений розробниками Microsoft. Жодної апаратної підтримки з боку процесора цей механізм не має. Система самостійно керує всіма типами переривань, що виникають через механізм відображення рівнів переривання апаратного контролера переривань (PIC) і власних програмних рівнів в єдину апаратно-незалежну таблицю рівнів переривань.

З цього твердження випливає, що модель власна, програмна, і рівні в ній не прив'язані до будь-якої специфікації обладнання, це дозволяє системі зібрати в єдину ієрархію пріоритетів апаратні та не апаратні типи переривань. Нижчі (не апаратні/програмні) рівні IRQL (PASSIVE, APC, DPC/DISPATCH) використовуються для синхронізації програмних підсистем операційної системи: запуску операцій планування, таких як перемикання потоків або обробка завершення вводу/виводу. Давайте розглянемо їх докладно:

• 0-й (нижчий) пріоритет IRQL (PASSIVE):є типовим рівнем запиту переривань, на якому проводиться робота в операційній системі, як в режимі користувача, так і в режимі ядра. Код (програма), що виконується на даному рівні, може бути елементарно перерваний (витіснений) всім чим завгодно: наприклад потоки, що виконуються з рівнем IRQ PASSIVE піддаються витіснення планувальником після закінчення кванта часу, виділеного для них.
• Рівні IRQL APC та DPC/DISPATCH - програмні рівні переривань, пов'язані з планувальником.
• 1-й рівень IRQL (APC):На цьому рівні виконуються так звані APC-процедури, тобто процедури, що виконуються асинхронно в контексті конкретного потоку, тобто організують асинхронне введення-виведення, або звертаються / чекають звільнення будь-яких (зовнішніх, глобальних) системних об'єктів. Використання APC-функцій (наприклад WaitForSingleObjectEx) у коді не призводить до миттєвого виконання функції, натомість потік (в контексті якого функція виконується) переходить у спеціальний статус та генерується програмне переривання APC, виклик функції ставиться у внутрішню чергу. Наступного разу, коли настав час виконувати цей поток, то запланована APC-функція виконується на рівні APC. Потоки, що працюють на рівні APC, відповідно не отримують запити свого рівня АРС, які система використовує для операцій завершення вводу/виводу.
• 2-й рівень IRQL (DPC/DISPATCH):
  • використовується для обробки відкладених викликів процедур (DPC): Відкладені виклики процедур - це підпрограми зворотного виклику, які відкладені для виконання до того моменту, коли відбудеться переключення на рівень IRQL DISPATCH; Зазвичай DPC вимагаються з високих рівнів IRQL з метою здійснення додаткової роботи, Для якої процесорний час, що витрачається, не критично. Це досить важлива для продуктивності стадія, і зараз поясню чому. Драйвери пристроїв намагаються виконувати мінімально-можливу кількість операцій усередині власних підпрограм обробки переривання (ISR), щоб не займати тривалий час на рівні DIRQL, тим самим не блокуючи решту переривань і не гальмуючи, у результаті, всю систему.

    Що рівень IRQL, то менше можливості процесу. Це спонукає розробників на високому рівні IRQL виконувати тільки найнеобхідніші операції, а всі інші дії робити на низькому.

    Якщо драйвер розуміє, що потрібно виконання додаткової роботи, яка займає суттєвий процесорний час, він запитує DPC і перекладає нього це завдання. Коли рівень IRQL опускається до DISPATCH, відбувається зворотний виклик відкладеної функції драйвера, яка і виконує частину обробки. Реалізуючи подібний алгоритм на рівні IRQL DISPATCH, драйвер проводить на рівні DIRQL меншу кількість часу, і, відповідно, зменшує час затримки на обробку власного переривання, тим самим звільняючи його для інших пристроїв системи.

  • використовується для виконання завдань планувальника: Як ви знаєте, в операційних системах лінійки Windows NT реалізована багатозадачність, що витісняє, що означає, що кожному процесу, що виконується в операційній системі, виділяється для виконання певний час. Оскільки IRQL планувальника потоків і DPC дорівнює 2, то він вище пріоритету потоків користувача (виконуються на рівні 0). У свою чергу пріоритет планувальника нижчий за пріоритет апаратних переривань (переривань від пристроїв), тобто він може бути перерваний апаратними перериваннями.

Добре, але я так і не зрозумів, чому не можна було відмовитись від усіх цих рівнів і зробити "плоску" модель черг, або виконувати всі ці типи завдань у міру надходження? Давайте змоделюємо робочу ситуацію:
представимо якийсь код, наприклад невелику програму, написану "на коліні". Ось ми запустили її на виконання, відповідно в системі сформувався процес для нашої програми, у контексті якого почав виконуватись основний потік. Типовий потік (режим користувача або режиму ядра) виконується на найнижчому рівні IRQL PASSIVE. Протягом усього часу виконання потоку годинник (мікросхема таймера) періодично генерує власні переривання для відліку тимчасових інтервалів, які використовуються для вказівки операційної системи про проходження заданого проміжку часу. Процедура обробки переривання годинника виконується на рівні IRQL CLOCK, який (якщо подивитися в таблицю) вище за пріоритетом більшості рівнів: і рівня DISPATCH, на якому виконується планувальник, і рівня PASSIVE, на якому виконується наша програма. Таким чином, таймер постійно витісняє роботу і планувальника і нашої програми. З кожним переданим тиком таймера, процедура обробки переривання таймера зменшує що залишається у виконується в Наразінашого потоку користувача квант часу. У момент, коли квант часу виконується потоку зменшується до нуля, програма обробки переривання годинника генерує переривання рівня DISPATCH, тим самим викликаючи запуск планувальника для вибору ним наступного потоку для виконання. За фактом генерування переривання рівня DISPATCH процедура обробки переривання таймера закінчує виконання свого коду і управління повертається ядру системи. Ядро знаходить у черзі запитів наступне переривання з пріоритетним рівнем, що у режимі очікування. Кожне переривання обслуговується по черзі. Коли всі переривання вище рівня DISPATCH обслуговуються, виконується процедура обробки переривання рівня DISPATCH. Ця програма обробки переривання обробляє список DPC, а потім викликає планувальник. Планувальник виявляє, що квант часу поточного потоку вичерпано, тобто зменшено до нуля, після чого Планувальник виконує алгоритм планування для вибору наступного потоку на виконання. Код поставленого виконання потоку буде виконано коли система опуститься до рівня IRQL PASSIVE.
Таким чином реалізується пріоритети, і, відповідно, витісняюча багатозадачність. Тепер уявіть, що ви приберете із системи ієрархію рівнів запитів переривань, як у цьому випадку поводитиметься система? У цій ситуації було б незрозуміло що і коли виконувати, система виконувала б всі завдання, що надходять у порядку черги, що призвело б до того, що потоки запросто могли б витіснити планувальник і тим самим взагалі зруйнувати або повністю вивести з стоячи витісняючу багатозадачність, що спричинило б у себе непередбачувану роботу ОС. Таким чином:

IRQL - рівень апаратно-програмної пріорітизації, що застосовується для синхронізації в операційних системах сімейства Windows, тобто рівні IRQL є основним методом, який використовується для вибудовування за пріоритетами всіх дій, що виконуються в операційній системі Windows протягом циклу роботи.

відповідно:

IRQL вказує пріоритет коду, що виконується на процесорі стосовно переривань та інших асинхронних (раптових) подій.

Призначення рівнів IRQL у системі такі:

1. Маскування: підвищення рівня переривання дозволяє відрізати (замасувати) нижчі рівні апаратних переривань на контролер PIC. Це дозволяє на якийсь час проігнорувати переривання, що виникають на більш низьких рівнях, тим самим виграючи час виконання процедури обробки апаратного переривання цьому рівні.
2. Апаратна синхронізація: синхронізація даних між потоками, що виконуються на різних процесорах/ядрах багатопроцесорної системи.
3. Програмна синхронізація: для визначення коли різні APC/DPC-процедури можуть бути обслужені, для визначення коли можуть бути обслужені програми користувальницького режиму.

Таким чином, на глобальному рівні механізм IRQL дозволяє підпрограмі операційної системи:

• Керувати повторною вхідністю (реєнтерабельність)
• Гарантувати, що може продовжувати роботу без пріоритетного переривання (витіснення) деякими іншими діями.

Синхронізація процесів - це механізм, що дозволяє забезпечити цілісність будь-якого ресурсу (файл, дані у пам'яті), що він використовується кількома процесами чи потоками у випадковому порядку.

Ну гаразд, а як це впливає на драйвера? Ми знаємо, що драйвера можуть бути користувальницького режиму і режиму ядра, відповідно, виконуються в режимі користувача і в режимі ядра. Звідси слідує що:

Код драйвера може виконуватись на різних рівнях IRQL.

І звідси випливають два досить важливі висновки:

1. Код драйвера є витісняється і переривається. Як і будь-який інший код у системі, він може бути перерваний у будь-який момент після закінчення виділеного кванта часу;
2. Код драйвера повинен використовувати ті чи інші набори системних функцій, залежно від рівня IRQL, на якому він виконується.

Уявіть ситуацію, коли код драйвера виконується на низькому рівні IRQL, модифікує об'єкт (наприклад, файл file.txt ), потім інший код на вищому рівні IRQL раптово перериває його виконання і модифікує той же файл file.txt іншими даними. Коли керування повернеться до драйвера, він продовжить модифікацію файлу своїми даними, тим самим затерши дані, що надійшли від іншого джерела. Таким чином, файл увійде в неузгоджений стан. Для вирішення подібних проблембуло введено різні системні об'єкти синхронізації. Для того, щоб код рівня ядра міг модифікувати певні типи даних, об'єкти взаємного виключення, він повинен спершу отримати володіння блокуваннями.

Драйвер концепції

Ядро операційної системи Windows не проектувалося для самостійної взаємодії з пристроями.

Відповідно висновки, які з цього твердження, очевидні: для взаємодії системи з пристроями потрібні окремі інтерфейси, можливо навіть складна сукупність кількох інтерфейсів. Концепція драйвера була розроблена для вирішення завдання сполучення та використовується в моделях більшості сучасних системВона заснована на роботі в адресному просторі ядра спеціального коду, який забезпечує взаємодію ядра системи з будь-яким типом логічних/фізичних пристроїв.
Враховуючи загальну орієнтованість ресурсу, у статті ми висвітлюватимемо специфіку виключно драйверів операційної системи Windows. Отже, для драйвера Windows, Як, загалом, драйверів інших операційних систем, вірні такі твердження:

Драйвер (Driver) - програмне забезпечення, за допомогою якого операційна система (програми користувача, ядро ​​та інші компоненти) отримують доступ до функціонала якогось фізичного або логічного пристрою.

те саме, але іншими словами:

Драйвер - інтерфейс між кодом режиму користувача, режиму ядра і функціями фізичного/логічного/віртуального пристрою.

Одне з наведених визначень наголошує на важливості драйвера: помилково представляти драйвер виключно у взаємодії з фізичним пристроєм, оскільки драйвер не обов'язково повинен надавати доступ до функцій будь-якого обладнання, він може забезпечувати і виключно програмні функціональні особливості. Прикладами таких рішень є драйвера, які встановлюються в систему антивірусами, системами шифрування даних, системами моніторингу. Загальний алгоритм роботи будь-якого драйвера наступний: програми за допомогою функцій спеціального інтерфейсу користувача (у Windows це API Win32) або запитів введення-виведення опосередковано/безпосередньо звертаються до функцій драйвера якогось пристрою. Драйвер, у свою чергу, надає доступ до функціональних особливостей пристрою, що цікавить, а так само контролює процес взаємодії між запитами додатків і безпосередньо пристроєм. Природно, що в драйвері повинні бути визначені (описані) всі принципи взаємодії з пристроєм, що обслуговується (підлеглим, власним), повинен бути присутнім набір даних про керований об'єкт, інструкції (набір команд), за допомогою яких системний/користувацький код може коректно ініціалізувати пристрій і почати з ним взаємодія.

Завантаження драйверів під час запуску операційної системи

Дуже цікаво було б побачити, на якій стадії завантаження операційної системи починає завантажуватися і починає виконуватися перший драйвер Windows? Однак у детальному викладі процес цей досить нетривіальний і для глибокого розуміння вимагає реверсингу коду багатьох компонентів завантаження, на додаток до всього необхідно враховувати безліч супутніх моментів, як-от: послідовність завантаження, обумовлену залежністю між драйверами, через яку драйвера можуть групуватися в так звані " групи завантаження", саме завантаження драйверів може розділятися на кілька етапів та інше. При цьому слід врахувати, що в Мережі є велика кількість матеріалів щодо вже застарілих операційних систем, тому ми спробуємо актуалізувати процес завантаження драйверів Windowsна прикладі (найближчої мені за духом) операційної системи Windows 7. І для початку не завадило б розповісти про основні компоненти ядра Windows, що беруть активну участь у процесі завантаження драйверів:

• Диспетчер (менеджер) вводу/виводу (I/O Manager)- модуль режиму ядра, що входить до складу виконавчої підсистеми, керує процесами введення/виводу, що забезпечує абстракцію фізичних та логічних пристроїв для додатків користувача та системних компонентів, що зв'язує програми користувальницького режиму з драйверами. Контролює стадії процесу взаємодії із драйверами. Весь обмін даними менеджера вводу-виводу з драйверами здійснюється через звернення до процедур зворотного виклику драйвера (callback) і передачі стандартизованої структури даних IRP, в якій описана вся суть звернення до драйвера;
• Диспетчер (менеджер) Plug-and-Play (PnP Manager)- модуль режиму ядра і режиму користувача, що входить до складу виконавчої підсистеми, що відповідає за додавання, розпізнавання, видалення пристроїв в операційній системі. Частина режиму ядра взаємодіє з іншими компонентами системи та драйверами в процесі встановлення (завантаження) програмного забезпечення, необхідного для обслуговування наявних у системі пристроїв. Частина режиму користувача відповідає за взаємодію з програмами режим користувача (для інтерактивної взаємодії з користувачем) у ситуаціях, що вимагають встановлення нових драйверів або налаштування робочих параметрів у існуючих. Керує розподілом апаратних ресурсів у системі, так само вміє розпізнавати пристрої, реагувати на їх підключення/відключення, завантажувати відповідні драйвера для виявлення нових пристроїв;
• Менеджер управління службами (Service Control Manager, SCM)- системний процес, відповідальний за створення, видалення, запуск та зупинку служб та драйверів операційної системи. Також забезпечує: функціонування журналу подій, підтримку технології віддаленого виклику процедур (remote procedure call, RPC);

Ці два менеджери, тобто менеджер введення-виводу та менеджер PnP, активно взаємодіють між собою.
Тепер ми опишемо процес завантаження операційної системи, проте зробимо це не у звичній нам формі, а коротко відзначимо ключові моменти щодо роботи описаних компонентів операційної системи з драйверами:

1. Bootmgr(.efi) завантажує модуль winload(.efi) і передає йому керування.
2. Winload(.efi) сканує кущ реєстру HKEY_LOCAL_MACHINE\System\servicesта отримує список усіх встановлених у системі драйверів. У цьому кущі реєстру присутні розділи, що зіставляються з кінцевими драйверами, в них присутні різноманітні параметри, що відносяться до драйверів, такі як Group , Start , Type , LoadOrderGroup , DependOnGroup , DependOnServices , що визначають ті чи інші кри.
3. Winload(.efi) завантажує драйвера, критичні для стадії завантаження/функціонування операційної системи, такі як драйвера контролерів накопичувачів, драйвера файлових систем. Очевидно, що подібні драйвера мають найвищий пріоритет, оскільки створюють базис для завантаження інших драйверів, тому внаслідок цих і інших причин повинні бути в пам'яті в момент передачі управління ядру. Відповідно, маркуються вони спеціальним типом SERVICE_BOOT_START. Драйвера на цьому етапі починають завантажуватися в залежності від груп, до яких вони належать.
4. Winload(.efi) завантажує безпосередньо ядро ​​з файлу ntoskrnl.exe та передає йому керування.
5. Ядро завантажує Менеджер вводу-виводу та PnP-менеджер.
6. Менеджер введення-виведення створює глобальний каталог. Цей каталог використовується для реєстрації об'єктів пристроїв.
7. PnP-менеджер стартує драйвера, вже завантажені на згадку на попередньому етапі (мають тип SERVICE_BOOT_START), викликаючи процедуру DriverEntry кожного драйвера. На цьому етапі завантажуються і залежні драйвера.
8. PnP-менеджер будує дерево пристроїв системи, обходить його з кореня і завантажує драйвера пристроїв, які ще не були завантажені.
9. PnP-менеджер завантажує драйвера пристроїв, що залишилися незавантаженими, незалежно від значення параметра Start . Багато подібних драйверів мають тип SERVICE_DEMAND_START .
10. PnP менеджер завантажує драйвера розширеного функціоналу. До таких драйверів відносяться драйвер відеоадаптера, драйвера. зовнішніх пристроївдрайвера стека TCP/IP. Такі драйвери мають тип SERVICE_SYSTEM_START.
11. Ядро завантажує Менеджер (диспетчер) керування сеансами/сесіями (Session Manager Subsystem Service, SMSS), який, у свою чергу, завантажує Менеджер (диспетчер) керування службами (SCM). SCM сканує кущ реєстру ( HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services) та на основі отриманої інформації монтує внутрішню базу даних служб/драйверів, формує програмний інтерфейсдля обслуговування встановлених служб/драйверів. SCM завантажує "автозапуск" не-PnP драйвера (мають тип SERVICE_AUTO_START), а також всі драйвера, від яких вони залежать.

З усього цього алгоритму завантаження драйверів нам необхідно усвідомити такі основні правила: драйвер може бути завантажений (залежно від стадії/класу драйвера) за допомогою PnP-менеджера або за допомогою SCM, а ось у процесі функціонування драйвера активно бере участь Менеджер введення-виводу .

Структура драйвера Windows

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

Драйвер - це свого роду "бібліотека режиму ядра", звичайний файл DLL, у якого в PE-заголовку (структура IMAGE_NT_HEADERS , підструктура OptionalHeader) значення поля Subsystem = 1 (IMAGE_SUBSYSTEM_NATIVE).

Тип підсистеми може бути заданий при складанні модуля, що виконується. Сама по собі нативна підсистема характерна для додатків, які функціонують за іншими, відмінними від класичних правил, на стадії підготовки образу до виконання їм не потрібно ініціалізація підсистеми Win32. Серед інших підсистема native використовується для коду режиму ядра, яким і є майже всі драйвера.

За аналогією з DLL, спрощено можна розглядати драйвер як набор процедур (викликаних зовнішніми програмами), кожна з яких призначається для обробки певного типу звернень до драйвера.

Зробимо невеликий відступ і поговоримо про таке поняття, як об'єкт. Справа в тому, що весь процес функціонування драйвера Windows, як і будь-яких інших модулів операційної системи, залежить від різноманітних системних структур даних. Ці структури управляються ядром і можуть містити в собі потоки, події, запити введення-виведення, пристрої та інші сутності.

• Об'єкти. Блоки даних, що містять записи властивостей тієї чи іншої сутності операційної системи. Керуються диспетчером (менеджером) об'єктів. Багато об'єктів мають дескриптори (описувачі), з яких об'єкт стає доступним додатків.
• Структура даних. Блоки даних, що містять записи властивостей тієї чи іншої сутності операційної системи. Керуються ядром. Відрізняються від об'єктів, проте (за інерцією) також називаються об'єктами

Тому (з великим натягом) усі внутрішні структури операційної системи Windows називають об'єктами.
Тепер повернемося до процедур драйвера, насправді так звані "процедури" драйвера є COM-об'єктами зворотного виклику, які обробляють події, що надходять від відповідних об'єктів інфраструктури операційної системи, говориться що драйвер надає ядру операційної системи COM-інтерфейс, заданий серією процедур, що реалізуються драйвером. Експорт, тобто публікація (оголошення) процедур драйвера для подальшого звернення до них ззовні, виконується шляхом реєстрації в основній процедурі драйвера (стандартної для всіх драйверів), що має назву DriverEntry.

Основне призначення функції DriverEntry полягає в тому, щоб розробник драйвера реалізував у ній заповнення об'єкта (записів структури) драйвера вказівниками на різні внутрішні процедури драйвера, що забезпечують той чи інший функціонал. У процедурі DriverEntry можна задавати (змінювати) ім'я об'єкта пристрою, яке згодом використовується програмами для відкриття дескриптора пристрою та надсилання пакетів запитів вводу-виводу (IRP).

Функція DriverEntry фактично є функцією глобальної ініціалізації і виконується один раз на етапі завантаження драйвера. Ця функція може бути як гранично простий, так і містити розширений функціонал (додаткові підпрограми), такий, як створення додаткових об'єктів пристроїв, опитування пристрою, додаткові фази конфігурації та ініціалізації пристроїв(а).
Після публікації своїх функцій драйвер стає " видимим " ядром операційної системи. Щоб не ускладнювати і так досить складну теорію, вважатимемо, що з погляду ядра Windows будь-який пристрій є якимось абстрактним " віртуальним пристроєм", що оперує стандартизованим набором команд, і доступним через внутрішні інтерфейси. Як вже було сказано вище, в ядрі операційної системи Windows присутній спеціальний модуль виконавчої системи, званий диспетчером (менеджером) введення-виводу, що забезпечує єдиний інтерфейс взаємодії всім драйверів режиму ядра, включаючи драйвери фізичних пристроїв, драйвери логічних пристроїв і драйвери файлових систем. Відповідно, система вводу-виводу ядра керує драйверами, або можна сказати, що драйвери використовують інтерфейс диспетчера вводу-виводу для забезпечення функціонування операційної системи. З іншого боку, драйвер забезпечує перетворення (конвертацію) "стандартних команд", що надходять від операційної системи, в команди, які "розуміє" підконтрольне йому пристрій (якщо воно є), і навпаки. Менеджер введення-виводу визначає набір (безліч) стандартних процедур, які можуть бути реалізовані в драйвері, оскільки:

Драйвер містить набір процедур зворотного дзвінка, які забезпечують різні стадії процесу введення-виведення.

Для глибшого розуміння того, які функціональні особливості повинен забезпечувати драйвер, давайте наведемо загальну схему ключових процедур драйвера:

Власне, дивлячись на наведену схему стає зрозуміло, які саме види взаємодії, а саме групи процедур повинен реалізовувати абстрактний драйвер Windows. Давайте тепер перерахуємо деякі з цих процедур:

• Ініціалізація - Менеджер вводу-виводу запускає процедуру ініціалізації (називається DriverEntry), яка призначається для проведення дій з початкового настроювання об'єкта драйвера, реєстрації всіх інших процедур драйвера, конфігурування підлеглого пристрою та виконання інших дій на користь розробника.
• Додавання пристрою - додати (додатковий) об'єкт "пристрій". У цій процедурі драйвер зазвичай створює об'єкти "пристрій" для кожного пристрою, який обслуговується драйвером. Зазвичай використовується для драйверів Plug-and-Play.
• Обробка – набір процедур диспетчеризації (обробки різних станів). Відкриття, закриття, читання, запис у пристрій, обробка станів живлення, подій PnP та станів системи, а також деякі інші види взаємодії описуються в процедурах диспетчеризації. Фактично це основні процедури, оскільки через процедури диспетчеризації обробляються типові операції вводу-виводу.
• Запуск (початок) введення-виведення - друга стадія обробки запиту введення-виводу до пристрою, що безпосередньо стартує введення-виведення пристрою. Ця процедура може використовуватися для початку передачі даних з пристрою.
• Процедура обслуговування переривання - коли пристрій генерує переривання, диспетчер переривань передає керування цією процедурою.
• Обробка відкладених дзвінків процедур - Процедура DPC перебирає основну роботу з обробці переривання після виконання ISR. Відкладені виклики процедур виконуються на низьких рівнях IRQL (DPC/DISPATCH), ніж сама процедура ISR. Реалізується подібний алгоритм для запобігання блокуванню інших переривань.
• Процедура завершення вводу-виводу - багаторівневий драйвер може мати процедури завершення вводу-виводу, які повідомляють про завершення обробки IRP низькорівневим драйвером.
• Процедури скасування введення-виводу - якщо операції вводу-виводу можуть бути перервані, драйвер може визначити одну або кілька подібних процедур. Коли драйвер отримує пакет IRP для запиту введення-виводу, який може бути скасований, він призначає процедуру скасування IRP, і пакет IRP проходить через різні стадії обробки, які ця процедура може змінити або прибрати, якщо поточна операція не скасовується.
• Процедура швидкого надсилання - Драйвера, які активно використовують Менеджер кешу, такі як драйвера файлових систем, зазвичай надають подібні процедури для забезпечення можливості обходу ядром типових алгоритмів обробки вводу-виводу.
• Процедура вивантаження - повинні бути реалізовані в кожному драйвері, який працює (звільняють/займають) із системними ресурсами, для того, щоб Диспетчер виводу-виводу вивантажити драйвер з пам'яті.
• Процедура попередження про завершення дозволяє драйверу звільнити всі займані ресурси при завершенні роботи системи.

Стає очевидним, що в процесі розробки драйвера Windows не стоїть завдання реалізувати весь набір описаних вище процедур, кожен драйвер унікальний і розробник може забезпечувати власний набір реалізацій, що підтримуються драйвером. Коли драйвер за допомогою PnP-менеджера або SCM завантажується в систему, диспетчер вводу-виводу створює у просторі імен об'єкт "драйвер" (driver object) і викликає процедуру ініціалізації драйвера (зазвичай це DriverEntry), яка виконує подальші дії з ініціалізації.

Об'єкт драйвера є образом завантаженого драйвера в пам'яті ядра і через даний об'єкт система керує драйвером.

Об'єкт драйвера представляє код і дані драйвера в ядрі: окрім іншого, через цей об'єкт драйвер експортує точки входу своїх процедур. Процедура ініціалізації драйвера записує в атрибути даного об'єкта точки входу всіх процедур драйвера, що експортуються. Після завантаження драйвер може створювати об'єкти "пристрій" для представлення пристроїв або навіть для формування інтерфейсу драйвера. Більшість драйверів створюють об'єкти "пристрій" таким чином:

• PnP-драйвери створюють об'єкти "пристрій" за допомогою своїх процедур додавання пристроїв, коли PnP-менеджер інформує їх про присутність керованого ними пристрою.
• не-PnP-драйвери створюють об'єкти "пристрій" при виклику менеджером введення-виведення їх процедур ініціалізації.

При створенні об'єкта типу "пристрій" (device), драйверу потрібно надати даному об'єкту ім'я. Потім цей новостворений об'єкт поміщається у простір імен диспетчера об'єктів(Object Manager), який, як і диспетчер (менеджер) введення-виведення, є частиною виконавчої підсистеми ядра. Менеджер об'єктів призначається для ведення бази всіх ресурсів операційної системи, представлених як об'єкти. Ім'я об'єкта може визначатися самим драйвером у явному вигляді, або автоматично генеруватися менеджером вводу-виводу. За згодою, об'єкти "пристрій" повинні розміщуватися в каталозі \Device простору імен менеджера об'єктів, недоступному програмам через Win32 API. А для того щоб об'єкт "пристрій" став доступним для додатків, драйвер повинен створити в каталозі \GLOBAL?? символьне посилання на ім'я цього об'єкта в каталозі \Device. Драйвери, які не підтримують технологію Plug-and-Play, та драйвери файлової системи зазвичай створюють символьне посилання із загальновідомим ім'ям (скажімо, \Device\VMwareKbdFilter). Тільки після всіх перерахованих дій драйвер стає "видимий" в системі і доступний для виклику користувачами додатками.

Взаємодія з драйвером

Яким чином програма користувача може взаємодіяти з драйвером в системі? На цей випадок є два способи:

1. Неявний - виклик типової функції Win32 API;
2. Явний - прямий запит введення-виведення до драйвера;

Ну з першим випадком все досить просто, у прикладній програмі викликається якась ординарна функція Win32 API (наприклад, CreateFile), яка, потім, залежно від цільового об'єкта (файлу, каталогу) може викликати в ланцюжку своїх викликів функцію обміну з драйвером. Фактично, в цьому випадку код програми не ставить своїм завданням взаємодіяти з будь-яким драйвером, просто по ланцюжку викликів процедур, на певному етапі виконання йде в режим ядра і відбувається виклик функції драйвера. Все це залишається прихованим від розробника, але можна відстежити взаємодію за допомогою налагоджувальних засобів.
Другий випадок більш цікавий, він виникає коли під викликом драйвера мається на увазі не опосередкований виклик (за допомогою виклику типової функції), а передача за допомогою спеціальної функції (наприклад, DeviceIoControl) так званого запиту введення/виводу (I/O control request), який, надалі, ініціює формування блоку даних під назвою пакета запиту введення-виведення.

Пакет запиту вводу-виводу (IRP, I/O Request Packet) - структура даних ядра Windows, що містить інформацію, що описує запит вводу-виводу.

Формально IRP це пакет, але це об'єкт ядра, тобто структура (блок) даних з набором процедур для менеджера вводу-вывода, що забезпечує обмін даними між програмою і драйвером, або між драйвером і драйвером. Як ми вже згадували, архітектура Windows побудована таким чином, що в ній заборонено пряму взаємодію програми режиму користувача та драйвера, тому подібний обмін зводиться до посилки програмою коду IOCTL, який вже призводить до формування менеджером введення-виведення IRP пакета запиту. Саме менеджер вводу-виводу як відповідальний за взаємодію з драйверами оперує пакетами IRP. Менеджер введення-виводу виходить запит на введення-виведення від програми користувача, потім формує IRP і передає його відповідному драйверу.
Пакет IRP складається із двох частин:

• постійної частини;
• стека розміщення вводу-виводу.

У постійній частині IRP містить старший та (не завжди) молодший код функції. Старші коди: IRP_MJ_CREATE , IRP_MJ_CLOSE , IRP_MJ_READ , IRP_MJ_WRITE , IRP_MJ_CLEANUP , IRP_MJ_DEVICE_CONTROL , IRP_MJ_INTERNAL_DEVICE_CONTROL , IRP_MJ_CROANUP J_POWER, IRP_MJ_PNP, IRP_MJ_SHUTDOWN. Пакет також містить стек розміщення вводу-виводу - спеціальну структуру IO_STACK_LOCATION , що містить певні параметри: це набір пристроїв, які оброблять цей пакет IRP. Причому стеку цей пакет передається послідовно від пристрою до пристрою. Більше ніж одне розміщення стека свідчить, що IRP може бути оброблений кількома драйверами. "Комірки стека" IRP і призначені для зберігання "змінної" інформації при ходженні пакету IRP по стеку драйверів. Пакет IRP проходить за опублікованими процедурами кожного драйвера, кожна з яких витягує зі "своєї" комірки стека розміщення вводу-виводу необхідну їй інформацію. Процедури драйвера зазвичай називаються "процедури зворотного виклику" (callback). Як ми вже згадували, функція ініціалізації драйвера DriverEtnry повідомляє ядру (публікує) імена цих процедур і пізніше ядро ​​саме викликає ту чи іншу процедуру за певних обставин.
На відміну від штатної програми драйвер не є класичним процесом зі своїм адресним простором і не має потоку виконання. Натомість, функція драйвера виконується в контексті потоку і процесу, в якому вона була викликана. Контекст (простір виконання коду) драйвера залежить від того, хто здійснює звернення (викликає) до драйвера. Звернення може бути ініційоване:

1. Прикладною програмою (програмою режиму користувача). У цьому випадку контекст виконання драйвера точно відомий і він збігається контекстом прикладної програми;
2. Іншим (стороннім) драйвером. У цьому випадку контекст виконання визначити складніше, він може бути як відомим, так і випадковим, це залежить від контексту виконання функції драйвера, що викликає.
3. Апаратним/програмним перериванням. У цьому випадку контекст виконання випадковий, оскільки переривання (і, відповідно, перемикання на код драйвера) може статися при виконанні будь-якого коду в операційній системі.

Знову ж таки, на відміну від штатної програми, драйвер не може викликати стандартні функції Win32 API, може лише оперувати доступними в ядрі функціями, які починаються з префіксів Ex.., Hal.., Io.., Ke.., Ks.., Mm.., Ob.., Po.., Ps. , Rtl.. , Se.. , Zw.. та деяких інших.

Види (типи) драйверів Windows

У процесі еволюціонування та, відповідно, ускладнення драйверної концепції драйвери почали підрозділятися на категорії (або типи) залежно від призначення. Ось основні з них:

• Драйвери класів(Class driver) – драйвери, розроблені Microsoft для певного класу пристроїв.
• Драйвери файлових систем(File System Drivers) - драйвери, що реалізують файлові системина різноманітних носіях інформації.
• Успадковані драйвера(Legacy drivers) - "застарілі" (сумісні за структурою зі старими версіями ОС) драйвери режиму ядра, які самостійно безпосередньо контролюють підлеглий пристрій без будь-яких додаткових драйверів пристрою. Чому вони мають таку назву? Це тип драйверів, що зберігся від перших версій ОС лінійки Windows NT.
• Драйвер шини (Bus driver) - Драйвери, що забезпечують функціонал будь-якої шини комп'ютера (ISA, PCI, USB, IEEE1394 та інших);
• Фільтруючі драйвери(Filter driver) - драйвери, які використовуються для моніторингу/зміни логіки іншого драйвера шляхом роботи з даними, що проходять через нього.
• Верхні фільтруючі драйвери(Upper-filter drivers) - підтип драйверів, що фільтрують, що знаходиться вище функціонального драйвера по стеку. Через верхні фільтруючі драйвери проходять всі запити, а це означає, що вони можуть змінювати та/або фільтрувати інформацію, що йде до функціонального драйвера, та й далі, можливо, до пристрою. Прикладами можуть бути фільтр-драйвер, який відстежує/фільтрує трафік, шифрує/перехоплює запити читання/запису. Такі драйвери використовуються у брандмауерах.
• Нижні фільтруючі драйвери(Lower-filter drivers) - підтип драйверів, що фільтрують, що знаходиться нижче функціонального драйвера по стеку. Через подібні нижні драйвери, що фільтрують, проходить, як правило, менше запитів у порівнянні з іншими фільтруючими драйверами, тому що більшість запитів виконує і завершує сам функціональний драйвер.
• Функціональні драйвери(Function driver) - драйвери, що функціонують самостійно та визначають всі аспекти, пов'язані з пристроєм.
• PnP драйвер (PnP Driver) – драйвер, що підтримує технологію Plug-and-Play;
• Мінідрайвер (мініпорт, міні-клас)(Miniport driver, Minidriver, Miniclass driver) - драйвери, які обробляють завдання, пов'язані з кінцевим пристроєм та використовують драйвера класу для керування пристроєм. Діють як одна з частин пари драйверів, в якій ця категорія діє як драйвер кінцевих пристроїв, що виконує специфічні завдання пристрою.

За рівнем компонетизації драйвери бувають:

• Однорівневі - обробка вводу/виводу реалізується в рамках одного модуля, що виконується (драйвера).
• Багаторівневі – обробка вводу/виводу розподіляється між декількома драйверами.

PnP драйвера під Windows поділяються на:

• Функціональний драйвер
• Драйвер шини (шинний драйвер)
• Драйвер-фільтр (фільтр-драйвер)

За режимом виконання драйвери Windows градуються:

• Драйвер для користувача режиму.
• Драйвер режиму ядра.

Моделі драйверів

Протягом усього часу існування операційної системи розробники намагалися стандартизувати та спростити розробку драйверів. Внаслідок чого з'явилися моделі.

Модель WDM

Колись дуже давно існувало два основних напрямки розвитку драйверної концепції Windows:

1. у Windows 95/98 застосовувалася модель VxD (Virtual Device Driver);
2. у Windows NT3.51 паралельно розвивалася модель NT-драйвер (драйвер у стилі NT, NT Driver).

Однак, починаючи з версії Windows 98/NT4.0, розробники зробили спробу уніфікувати (універсалізувати) розробку драйверів, внаслідок чого на зміну згаданим моделям прийшла нова модель WDM.

WDM (Модель драйвера Windows, Windows Driver Model) – єдине середовище розробки (фреймворк) для драйверів пристроїв операційної системи Windows. Була створена зменшення коду стандартизації вимог до драйверам.

Модель WDM був етапом перевизначення класичного стека драйвера Windows з метою забезпечення підтримки революційних технологій Plug-and-Play і ACPI, що є на той час. Модель дає можливість завантажувати/вивантажувати драйвери "на льоту", без необхідності перезавантаження операційної системи, розробляти драйвера у вигляді розширень (фільтрів) до стандартних системних драйверів, гнучкіше керувати енергозбереженням і конфігурацією пристроїв та інше.
В рамках моделі WDM будь-який апаратний пристрій підтримується як мінімум двома драйверами:

• Функціональний драйвер (Function driver) - відповідальний майже за всі функціональні особливості пристрою, що обслуговується: операції вводу-виводу, обробка переривання і управління пристроєм;
• Драйвер шини (Bus driver) – відповідальний за обслуговування з'єднання між пристроєм та комп'ютером, фактично підтримкою сполучної шини (наприклад, PCI, USB та інші).

Модель WDF

Протягом усього часу розвитку модель WDM зазнавала безліч змін, суттєво розростаючись. Починаючи з Windows Vista була зроблена чергова спроба розвитку концепції драйвера Windows, по суті вже існувала на той момент моделі WDM, результатом чого стала нова модель (надбудови над WDM) під назвою WDF.

WDF (Основа драйверів Windows, Windows Driver Foundation) - середовище розробки (набір інструментальних засобів), що полегшує розробку драйверів пристроїв для операційних систем Windows (Windows 2000 і пізніших).

Пов'язано це було з незаперечним фактом, що розробникам не вдалося досягти достатнього рівня абстракції моделі WDM, а саме недостатньою інтеграцією підсистеми введення-виведення з технологією Plug-and-Play та управлінням живленням. Це призводило до того, що на розробнику драйвера лежало величезне навантаження щодо синхронізації цих запитів введення-виводу з подіями Plug-and-Play і запитами енергоспоживання. Очевидно, потрібно подальше спрощення драйверної моделі. WDF прийшла на зміну WDM і вважається найсучаснішою моделлю.
WDF реалізує такі можливості:

1. "Винесення" деяких некритичних до режиму виконання класів драйверів в режим користувача, що дало скорочення загальної кількості збоїв в ядрі.
2. Більшість обробки взаємодії підсистеми вводу-виводу з Plug-and-Play та керуванням електроживленням виконується тепер вбудованими механізмами моделі WDF.
3. Надання нових внутрішніх інтерфейсівмоделі WDF, які дозволяють абстрагуватися від складніших для розуміння системних інтерфейсів; У моделі WDM/legacy досить складно реалізувати логіку деяких частин взаємодії з драйвером, не вивчивши всі ази складної архітектури ядра, WDF дозволяє автоматизувати багато видів взаємодії; Велика кількість коду при розробці драйвера WDM тепер може бути замінена викликами процедур WDF.
4. Можливість створення "канонічного" драйвера. Присутність шаблонів, які надають сторонньому розробнику можливість перевизначення унікальних для драйвера його критеріїв, тим самим скорочуючи час на розробку.

Модель WDF поділяється на два напрямки:

• UMDF (Kernel-Mode Driver Framework) – середовище розробки драйвера режиму ядра.
• KMDF (User-Mode Driver Framework) – середовище розробки драйвера режиму користувача.

Підрозділ середовищ за режимами користувача та ядра моделі WDF досить умовне, оскільки основне призначення даного розмежування полягає в класифікації розробки драйверів для тих чи інших класів пристроїв.