Розробка та дослідження драйверу консолі

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

“Розробка та дослідження драйверу консолі”

ЗМІСТ

• ВСТУП
• 1. ПРИЗНАЧЕННЯ ДРАЙВЕРІВ ТА ПОРЯДОК РОБОТИ З ДРАЙВЕРАМИ В MS-DOS
• 2. РОЗРОБКА ДРАЙВЕРА КОНСОЛІ
• 2.1 СТРУКТУРА ДРАЙВЕРА ТА ПРИЗНАЧЕННЯ КОМПОНЕНТІВ
• 2.2 ФОРМУВАННЯ СЛОВА АТРИБУТУ ДРАЙВЕРА
• 2.3 РОЗРОБКА СХЕМИ АЛГОРИТМУ ДРАЙВЕРА
• 2.4 ОПИС ЗМІННИХ ДРАЙВЕРА
• 2.5 ОПИС РОБОТИ КОМАНД ДРАЙВЕРА
• 3. РОЗРОБКА ПРОГРАМИ ВІДЛАГОДЖЕННЯ ДРАЙВЕРА
• 3.1 СТРУКТУРА ПРОГРАМИ ТА ПРИЗНАЧЕННЯ КОМПОНЕНТІВ
• 3.2 РОЗРОБКА СХЕМИ АЛГОРИТМУ ПРОГРАМИ
• 3.3 ОПИС ЗМІННИХ ПРОГРАМИ ТА РОБОТИ МОДУЛІВ ПРОГРАМИ
• 3.4 АНАЛІЗ РОБОТИ ПРОГРАМИ ВІДЛАГОДЖЕННЯ ДРАЙВЕРУ
• 4. РОЗРОБКА ПРОГРАМИ ДОСЛІДЖЕННЯ РОБОТИ ВСТАНОВЛЕНОГО ДРАЙВЕРА
• 4.1 ПРИЗНАЧЕННЯ ПРОГРАМИ
• 4.2 РОЗРОБКА СХЕМИ АЛГОРИТМУ ПРОГРАМИ
• 4.3 ОПИС ЗМІННИХ ПРОГРАМИ ТА РОБОТИ МОДУЛІВ ПРОГРАМИ
• 4.4 АНАЛІЗ СХЕМ АЛГОРИТМІВ ВЗАЄМОДІЇ ФУНКЦІЙ 08h, 3Fh, 0Bh int 21h З ДРАЙВЕРОМ.
• 4.5 АНАЛІЗ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ РОБОТИ В РЕЖИМАХ binary і ASCII
• 4.6 АНАЛІЗ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ РОБОТИ В РЕЖИМІ ВІДКРИТОГО ДРАЙВЕРА
• 4.7 АНАЛІЗ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ РОБОТИ В РЕЖИМІ ЗАКРИТОГО ДРАЙВЕРА
• 4.8 РОЗРОБКА ПРОГРАМНОЇ МОДЕЛІ ЗАДАНИХ ФУНКЦІЙ int 21h
• 4.9 ЗАМІНА ПРОГРАМНОГО ПЕРЕРИВАННЯ int 21h НА СМОДЕЛЬОВАНИЙ ОБРОБНИК
• 4.10 АНАЛІЗ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ РОБОТИ ДРАЙВЕРА ПРИ УСТАНОВЦІ МОДЕЛЬНОГО ОБРОБНИКА ПЕРЕРИВАННЯ
• 5. РОЗРОБКА ПРОГРАМИ ФОРМУВАННЯ СПИСКУ ДРАЙВЕРІВ
• 5.1 ПРИЗНАЧЕННЯ ПРОГРАМИ
• 5.2 РОЗРОБКА СХЕМИ АЛГОРИТМУ ПРОГРАМИ
• 5.3 АНАЛІЗ РЕЗУЛЬТАТІВ РОБОТИ ПРОГРАМИ
• 5.4 ОПИС ЗМІННИХ ПРОГРАМИ ТА РОБОТИ МОДУЛІВ ПРОГРАМИ
• 5.5 РОЗРОБКА РЕЖИМУ ВИДАЛЕННЯ ДРАЙВЕРА З ЛАНЦЮГА ДРАЙВЕРІВ
• 5.6 РОЗРОБКА РЕЖИМУ ВИДАЛЕННЯ ЗАМІНЮЮЧОГО ДРАЙВЕРА КОНСОЛІ
• ВИСНОВОК
• СПИСОК ЛІТЕРАТУРИ
• Додаток 1. Лістінг програми драйверу
• Додаток 2. Лістінг програми відлагодження драйвера
• Додаток 3. Лістінг програми дослідження драйвера
• Додаток 4. Лістінг програми формування списку встановлених драйверів
• ВСТУП
• Даний курсовий проект присвячений вивченню принципів внутрішньої організації декілька застарілої операційної системи MS - DOS. MS - DOS - це перша операційна система від Microsoft, яка значно розповсюдилася серед персональних комп'ютерів якийсь час тому, але її розвиток був згодом перерваний (десь на початку 90-х минулого сторіччя) тому, що вона мала багато недоліків - відсутність яскравого графічного інтерфейсу, однозадачність, і т.п. Як і в будь-якій сфері, що розвивається, з'явилися нові ідеї (ефективніші, й надійніші) програма застаріла. MS-DOS змінила інша розробка від компанії Microsoft - всім відома операційна система MS Windows, яка зараз знаходиться назовсім іншому ступеню розвитку ніж колись MS-DOS.
• Вивчення цього програмного продукту виправдано з учбовими цілями. MS-DOS організована набагато простіше ніж ОС Windows, тому, потрібно почати фундаментальне вивчення ОС саме з MS-DOS, щоб вивчивши фундаментальні істини прийти до більш складніших.
• 1. ПРИЗНАЧЕННЯ ДРАЙВЕРІВ ТА ПОРЯДОК РОБОТИ З ДРАЙВЕРАМИ В MS-DOS
• Робота зі всіма пристроями в комп'ютері здійснюється через драйвери. Така структура DOS дозволяє розширити стандартні функції і організувати обмін інформацією практично з будь-яким цифровим пристроєм.
• Пристрої розділяються на 2 групи: символьні і блокові.
• Символьні передають по одному символу, наприклад клавіатура модем та інші.
• Блокові пристрої передають дані блоками по декілька байт, наприклад 512 або 1024 байт. Це диски, дисководи. Розділення на такі групи дає великі переваги, тому що операційна система працює з пристроєм, не дивлячись на його апаратні особливості.
• Обмін між драйверами і операційною системою відбувається за допомогою запитів. Запит містить всю необхідну інформацію для роботи пристрою: яку команду потрібно виконати, в якому вигляді повернути дані і т.п. Також запит є уніфікованою структурою, що дуже спрощує роботу прикладних програм з пристроєм.
• Нижче на рисунку 1.1 приведена схема взаємодії прикладної програми і пристрою. Безпосереднє управління пристроєм з програми доцільно застосувати для організації обміну інформацією з нестандартним пристроєм. Робота через BIOS менш складне завдання, але використання цього методу обмежує можливості програми, оскільки можна реалізувати обмін інформацією лише із стандартними пристроями. Найбільш поширений спосіб роботи з пристроями, причому не тільки в MS-DOS, - робота через драйвери. Всі мови високого рівня для введення-висновку використовують функції int21h або функції драйвера.

• Рисунок 1.1 - Взаємодія програми з MS-DOS, BIOS і апаратурою
• Системний файл MS-DOS з ім'ям io.sys містить драйвери для деяких пристроїв. Ці драйвери з'являються в пам'яті при завантаженні операційної системи і зв'язані в ланцюжок через поля next в своїх заголовках. Такі драйвери ми називатимемо резидентними драйверами MS-DOS.
• Резиденті драйвери можна замінити драйверами користувача. Крім того, користувач може додати в список драйверів нові.
• Для підключення драйвера до операційної системи файл config.sys повинен містити рядок наступного вигляду:
• Device=<путь_файла_драйвера>_<параметри>.
• Параметри зчитуються драйвером один раз в процесі ініціалізації драйвера.
• Завантажуванні додатково драйвери знаходяться у списку драйверів перед резидентними драйверами.
• 2. РОЗРОБКА СИМВОЛЬНОГО ДРАЙВЕРА КОНСОЛІ
• 2.1 СТРУКТУРА ДРАЙВЕРА ТА ПРИЗНАЧЕННЯ КОМПОНЕНТІВ
• Драйвер починається з управляючого блоку, - це так званий заголовок драйвера. В таблиці 2.1 наведені поля заголовка драйвера. Тільки на відміну від заголовка exe-програм, заголовок драйвера створюється не редактором зв'язку, а самим програмістом і повинен бути поміщений в початок тексту програми-драйвера.
• Таблиця 2.1 - Заголовок драйвера

Зсув, байт	Розмір, байт	Ім'я поля	Опис
0	4	next	Покажчик на заголовок наступного драйвера. Якщо зсув адреси наступного драйвера рівний FFFFh, це останній драйвер в ланцюжку.
4	2	attrib	Атрибут драйвера
6	2	strateg	Зсув програми стратегії драйвера
8	2	interrupt	Зсув програми обробки переривання для драйвера
10	8	dev_name	Ім'я пристрою для символьних пристроїв або кількість обслуговуваних пристроїв - для блокових пристроїв

• При завантаженні драйвера в пам'ять заголовок драйвера теж поміщається в оперативну пам'ять.
• Для завантаженого в пам'ять драйвера ніколи не створюється префікс програмного сегменту PSP.
• Всі драйвери зв'язані в ланцюжок. Найперший драйвер знаходиться відразу за векторною таблицею зв'язку. Поле next заголовка драйвера указує на наступний драйвер (на його заголовок). Це поле має формат дальнього покажчика. Ознакою того, що даний драйвер є останнім в ланцюжку, служить значення 0FFFFh в компоненті зсуву поля next.
• Програміст, коли він складає програму-драйвер, заносить в це поле або 0FFFFh:0FFFFh, якщо початковий текст містить тільки один драйвер, або адреса наступного драйвера (у вигляді дальнього покажчика на мітку заголовка наступного драйвера). Якщо початковий текст містить декілька драйверів, то в заголовку останнього драйвера в полі next повинне знаходитися значення 0FFFFh:0FFFFh.
• При завантаженні драйверів в пам'ять операційна система змінить вміст поля next в заголовках драйверів для того, щоб це поле указувало на заголовок наступного драйвера в ланцюжку (у пам'яті, а не у файлі драйвера).
• Наступне поле в заголовку драйвера - поле атрибутів драйвера attrib.
• Це поле описує пристрій, який обслуговує драйвер. Кожен біт слова відповідає за ту або іншу особливість пристрою.
• Після слова атрибутів драйвера знаходяться: зсув програми стратегії драйвера strateg і зсув програми обробки переривання interrupt. Ці дві програми використовуються MS-DOS для організації виклику драйвера.
• Для звернення до драйвера MS-DOS формує в своїй області даних запит, що складається із заголовка стандартного формату і додаткової структури даних (змінній частині запиту), довжина і формат якої залежать від типу запиту. Після цього MS-DOS читає із заголовка драйвера зсув програми стратегії і передає їй управління, записавши в регістри ES:BX адресу заголовка запиту.
• Завдання програми стратегії - запам'ятати цю адресу усередині тіла драйвера для подальшого використання або організувати чергу запитів обслуговування.
• Відразу після виклику програми стратегії MS-DOS викликає програму обробки переривань, визначивши її адресу з поля interrupt заголовка драйвера.
• Програма обробки переривання витягує тільки що записану програмою стратегії адресу заголовка запиту і виконує ту функцію, номер якої записаний в запиті. Номер функції знаходиться в заголовку запиту. Результати виконання функції програма переривання записує в спеціально відведені поля заголовка запиту, після чого процедура звернення MS-DOS до драйвера завершується.
• Останнє поле заголовка драйвера dev_name для символьних пристроїв містить ім'я пристрою, вирівняне по лівому краю. Це ім'я використовуватиметься для звернення до драйвера. Ім'я пристрою не повинне співпадати з ім'ям файлу, що містить символьний драйвер, інакше не можлива робота з файлом драйвера.
• Для заміни драйвера стандартного символьного пристрою MS-DOS на свій, ім'я пристрою записується прописними буквами.
• Отже, після заголовка драйвера знаходяться: програма стратегії і переривання, також можуть існувати області даних, використовувані драйвером, і функції, стратегії, що викликаються програмами, і переривання. Іноді драйвери перемикають на себе деякі вектори переривань, і тоді вони містять в собі обробники цих переривань. В області пам'яті, відведеною операційною системою драйверу, може розташовуватися стек драйвера, якщо розмір системного стека недостатній. Структура драйвера зображена на рисунку 2.1.

На довжину драйвера накладається таке ж обмеження, як і на довжину com-програм - 64 Кбайт, тобто один сегмент. Текст програми приведений у додатку А.

Рисунок 2.1 - Структура драйвера

2.2 ФОРМУВАННЯ СЛОВА АТРИБУТУ ДРАЙВЕРА

Залежно від пристрою обслуговуваного драйвером і спираючись на таблицю 2.2 - складається слово атрибутів драйвера.

Таблиця 2.2 - Призначення окремих бітів слова атрибутів символьного драйвера

Біти	Призначення
0	1 - драйвер обслуговує стандартний пристрій введення; 0 - цей драйвер не обслуговує стандартний пристрій введення
1	1 - драйвер обслуговує стандартний пристрій виведення; 0 - драйвер не обслуговує стандартний пристрій виведення
2	1 - драйвер стандартного пристрою NUL; 0 - драйвер не обслуговує пристрій NUL
3	1 - драйвер обслуговує годинник
4	Для роботи з пристроєм можна використовувати засіб швидкого символьного виведення - переривання INT 29h. Це переривання призначене для швидкого виведення символу на консоль, код символу необхідно записати в регістр AL
5	Зарезервовано, біт повинен бути рівний 0
6	1 - дозволено використання драйвером функцій IOCTL; 0 - функції IOCTL не підтримуються
7	1 - пристрій може приймати запити IOCTL
8-10	Ці біти зарезервовані і повинні бути рівні 0
11	1 - підтримуються функції відкриття/закриття пристрою 0 - функції OPEN/CLOSE для символьних пристроїв не підтримуються
12	Зарезервовано, біт повинен бути рівний 0
13	1 - для символьних пристроїв підтримується функція виведення до отримання стану зайнятості пристрою; 0 - функція виведення до стану зайнятості не підтримується
14	1 - підтримуються функції читання і запису через інтерфейс IOCTL 0 - функції читання/запису через інтерфейс IOCTL не підтримуються
15	1 - символьний пристрій; 0 - блоковий пристрій

2.3 РОЗРОБКА СХЕМИ АЛГОРИТМУ ДРАЙВЕРА

Алгоритм роботи драйвера має наступний вигляд:

Рисунок 2.3 - Структурна схема алгоритму драйвера

Рисунок 2.4 Алгоритм процедури „Стратегія”

На рисунках 2.3, 2.4 приведені блок-схеми алгоритмів розглянутих раніше, вони досить прості і не вимагають додаткового тлумачення.

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

· отримавши управління від операційної системи, програма переривання зберігає вміст всіх регістрів процесора і прочитує номер команди із заголовка запиту;

· при необхідності програма прочитує додаткову інформацію з області запиту;

· команда, що жадалася, виконується (якщо вона підтримується драйвером);

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

· програма переривання встановлює слово стану пристрою відповідно до результатів виконання команди (якщо драйвер не підтримує команду, що зажадалася, в слові стану пристрою встановлюються біти 15 і в біти 0-7 записується код помилки 3 _ невідома команда);

· програма переривання відновлює вміст регістрів процесора, услід за чим управління повертається операційній системі (за допомогою команди повернення з дальньої процедури).

Рисунок 2.5 - Алгоритм програми „Прерывания”

Блок схема роботи програми переривання зображена на рисунку 2.5.

2.4 ОПИС ЗМІННИХ ДРАЙВЕРА

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

next_dev dd - вказівник на наступний драйвер у списку

attribute dw - змінна для збереження байту атрібутів

strategy dw - адрес процедури стратегія

interrupt dw - адрес процедури переривання

dev_name - строка, яка містить імя драйвера (CON)

Також драйвер має іще змінні для виведення лічильників.

Після завантаження драйвер стає як би частиною операційної системи. Всі звернення до драйвера MS-DOS виконує з використанням заголовка драйвера.

Отже робота з драйвером починається з формування ОС MS-DOS в своїй внутрішній області даних запиту до драйвера.

Запит операційної системи до драйвера містить заголовок, що має фіксований формат, вказаний в таблиці 2.3 і довжину 13 байт, а також структуру змінного розміру і формату, які залежать від виконуваної функції (змінна область запиту).

Таблиця 2.3 - Формат фіксованої частини заголовка запиту

Зсув, байт	Розмір, байт	Ім'я поля	Опис
0	1	size	Загальний розмір блоку запиту в байтах (довжина заголовка запиту плюс довжина змінної частини запиту)
1	1	unit	Номер пристрою. Використовується для блокових пристроїв; указує, з яким саме пристроєм (з числа обслуговуваних даним драйвером) працюватиме операційна система
2	1	cmd	Код команди, яку потрібно виконати. Може мати значення від 00h до 18h
3	2	status	Слово стану пристрою. Заповнюється драйвером перед поверненням управління операційній системі
5	8	reserved	Зарезервовано

Після виклику програми стратегії MS-DOS передає управління програмі переривання (без параметрів). Завдання програми переривання - виконати команду, код якої знаходиться в полі cmd заголовка запиту.

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

Крім того, драйвер повинен встановити слово стану пристрою (таблиця 2.4) status в заголовку запиту відповідно до результатів виконання команди.

Якщо драйвер не може виконати запитану команду, то він зобов'язаний в полі код помилки (у слові стану пристрою) видати відповідний код, відповідно до таблиці 2.5.

Таблиця 2.4 - Призначення окремих біт слова стану пристрою

Битий	Призначення
0-7	Код помилки пристрою. Якщо команда виконана з помилкою і драйвер встановив ознаку помилки (біт 15) в одиницю, він повинен записати в це поле код помилки
8	Команда виконана. Цей біт завжди встановлюється драйвером перед поверненням управління операційній системі
9	Зайнято. Цей біт встановлюється обробником команди, коли фізичний пристрій зайнятий виконанням попередньої операції і тому не може виконати нову команду. Даний біт використовується також для передачі інформації про те, що буфер клавіатури містить дані або про те, що середовище носія даних може бути замінене (у команді перевірки можливості заміни середовища носія даних)
10-14	Зарезервовано
15	Ознака помилки. Встановлюється драйвером, коли він не може обробити запит або відбулася фізична або логічна помилка при обробці правильного запиту. Биті 0-7 при цьому повинні містити код помилки

Таблиця 2.5 - Коди помилок пристрою

Код	Опис
0	Порушення захисту від запису. Була зроблена спроба запису інформації на захищений від запису пристрій
1	Невідомий пристрій
2	Пристрій не готовий
3	Невідома команда. Дана команда не підтримується драйвером
4	Помилка CRC. При виконанні команди виявлена помилка в контрольній сумі
5	Неправильна довжина запиту. Поле довжини в заголовку запиту містить невірне значення
6	Помилка при пошуку доріжки (доріжка не знайдена)
7	Невідомий носій даних
8	Сектор не знайдений
9	У принтері немає паперу
0Ah	Помилка запису
0Bh	Помилка читання
0Ch	Загальна помилка
0Dh	Зарезервовано
0Eh	Зарезервовано
0Fh	Зміна диска не дозволена

2.5 ОПИС РОБОТИ КОМАНД ДРАЙВЕРА

Ініціалізація драйвера (0)

Ця команда виконується тільки один раз при завантаженні драйвера.

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

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

Потім драйвер може виконати ініціалізацію обслуговуваного периферійного пристрою, ініціалізацію своїх внутрішніх змінних, вивести на екран які-небудь повідомлення, або навіть запитати у оператора додаткові дані. Для організації діалогу з оператором і інших дій обробник команди ініціалізації може користуватися функціями переривання INT 21h з номерами від 01h до 0Ch, 25h, 30h, 35h і функціями BIOS .

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

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

На рисунку 2.6 приведений алгоритм команди INIT, а в таблиці 2.6 формат запиту до цієї команди.

Таблиця 2.6 - Формат запиту для ініціалізації

Зсув, байт	Розмір, байт	Ім'я поля	Опис
0	13	header	Заголовок запиту
13	1	n_units	Кількість пристроїв, що обслуговуються драйвером. Це поле заповнюється тільки блоковим драйвером. Для символьного драйвера в це поле потрібно записати значення 0
14	4	end_addr	Дальня адреса нижньої межі резидентної частини коду драйвера. У це поле драйвер записує адреса байта пам'яті, наступного за областю драйвера, яка повинна стати резидентною
18	4	parm	Дальня адреса рядка параметрів ініціалізації драйвера з файлу config.sys. Цей рядок містить все, що знаходиться в рядку файлу після команди 'DEVICE='. Вона закінчується символами перекладу рядка і повернення каретки 0Ah, 0Dh. При поверненні драйвер блокового пристрою повинен записати в полі parm адресу масиву покажчиків на блоки параметрів BIOS (BPB), по одному покажчику на кожен пристрій, що обслуговується драйвером.
22	1	drive	Номер пристрою. У це поле при завантаженні драйвера операційна система заносить номер, призначений пристрою, що обслуговується драйвером. Наприклад, для пристрою А: це 0, для B: - 1 і т.д.
23	1	msg_flag	1 - відображення повідомлення про помилку, якщо в полі status заголовка запиту встановлені відповідні біти; 0 - повідомлення про помилку не відображається



Рисунок 2.6 - Алгоритм процедури „INIT”

Читання (введення)(4)

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

У операції читання беруть участь байти. Область запиту містить покажчик на буфер обміну. У цей буфер потрібно помістити прочитані дані. Далі слідує поле кількості передаваних байт.

Крім того, драйвер повинен повернути кількість дійсно прочитаних байт.

Після виконання операцій читання драйвер обов'язково повинен записати в полі count кількість дійсно переданих байт. У разі помилки недостатньо тільки встановити ознаку і код помилки в слові стану драйвера - потрібно також записати правильне значення в полі count.

У таблиці 2.7 приведений формат запиту для команди введення, а на рисунку 2.7 алгоритм її роботи.

Таблиця 2.7 - Формат запиту для читання

Зсув, байт	Розмір, байт	Ім'я поля	Опис
0	13	header	Заголовок запиту
13	1	media	У цьому полі драйверу передається байт-описувач середовища носія даних.
14	4	buf_adr	Адреса буфера для передачі даних.
18	2	count	Кількість переданих байтів
20	2	sector	Це поле не використовується символьними драйверами
22	4	vol_id	Це поле не використовується символьними драйверами
26	4	sect32	Це поле не використовується символьними драйверами



Рисунок 2.7 - Алгоритм команди введення

Неруйнуюче читання без очікування (5)

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

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

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

Ця команда використовується перед командою читання, для того, щоб перевірити, чи є в буфері дані, готові для читання. Така перевірка дозволяє уникнути тривалого очікування готовності даних при введенні. Крім того, команда використовується для перевірки наявності в буфері клавіатури коду комбінації клавіш <Ctrl+Break>.

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

Таблиця 2.8 - Формат запиту для не руйнуючого читання

Зсув, байт	Розмір, байт	Ім'я поля	Опис
0	13	header	Заголовок запиту
13	1	byte	У це поле драйвер записує витягнутий з буфера байт, який буде зчитаний наступною командою введення



Рисунок 2.8 - Алгоритм команди неруйнуюче введення

3. РОЗРОБКА ПРОГРАМИ ВІДЛАГОДЖЕННЯ ДРАЙВЕРА

3.1 СТРУКТУРА ПРОГРАМИ ТА ПРИЗНАЧЕННЯ КОМПОНЕНТІВ

Програма налагодження драйверу складається з двох модулів. Перший модуль test1.cpp є головним. Другий - це сам драйвер, який є об'єктом тестування. За допомогою головного модуля користувач може вибрати потрібний йому пункт меню, а саме: можна безпосередньо протестувати команди Init, Input та Nd_Inp без реального завантаження драйверу в систему та ризику щодо невірного функціонування та збою в роботі. В модулі test1.cpp формується запит відповідної команди та направляється до другого модуля. Задача драйверу як другого модулю - коректно прийняти адресу заголовка запиту від першого і обслугувати цей запит.

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

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

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

Лістінг програми наведено у додатку Б.

3.2 РОЗРОБКА СХЕМИ АЛГОРИТМУ ПРОГРАМИ

Програма являє собою окремі частини, вибір яких призводить до тестування відповідних команд драйверу (рисунок 3.1).

Рисунок 3.1 - Блок-схема алгоритму програми відлагодження драйверу

Тестування кожної команди складається з наступних етапів:

· Збереження в регістровій парі ES:BX адреси запиту;

· Виклик процедури Стратегія;

· Виклик процедури Переривання;

· Відображення результатів роботи драйверу та/або запиту зі зміненими байтами - свідченням виконання команди драйвером.

Цей алгоритм зображений на рисунку 3.2.

Рисунок 3.2 - Блок-схема алгоритму тесту команди

3.3 ОПИС ЗМІННИХ ПРОГРАМИ ТА РОБОТИ МОДУЛІВ ПРОГРАМИ

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

На рисунку 3.3 можна побачити головне вікно програми тестування.



Рисунок 3.3 - Головне вікно програми тестування

3.4 АНАЛІЗ РОБОТИ ПРОГРАМИ ВІДЛАГОДЖЕННЯ ДРАЙВЕРУ

При тестуванні команд виводився запит до виконання команди та після. Між цими двома виводами видавалися результати обробки команд драйвером.

Команда Init при тестуванні, як і очікувалося, видала повідомлення про ініціалізацію драйвера, змінила байти статусу, а також визначила та повернула адрес кінця резидентної частини драйвера. Статус виконання дорівнював 0100h, що є нормальним завершенням команди. Також, як можна бачити, змінився на 1 лічильник виконання команди. Результати роботи приведені на рисунках 3.4, 3.5, 3.6.

Рисунок 3.4 - Запит до роботи команди Init



Рисунок 3.5 - Робота команди Init

Рисунок 3.6 - Запит після роботи команди Init

Виконання команди Input потребує вказати кількість символів які треба запросити у драйвера, тому спершу вводиться кількість символів, потім на екран виводиться запит до драйверу (Рисунок 3.7), роботу команди (Рисунок 3.8), потім бачимо запит після виконання команди(Рисунок 3.9), також бачимо лічильники, і робімо висновки що до роботи команди.

Рисунок 3.7 - Запит до драйверу(команда Input)



Рисунок 3.8 - Робота команди Input

Рисунок 3.9 - Запит після виконання команди Input

Команда Nd_Input повернула у запиті введений символ, залишивши його у буфері для команди введення. Статус виконання - 0100h.

На рисунках 3.10, 3.11, 3.12, приведені результати роботи у вигляді запиту та буферу клавіатури, був, як і в попередній раз, інкрементований лічильник виконання відповідної команди.

Рисунок 3.10 - Запит до виконання команди ND_Input



Рисунок 3.11 - Запит після виконання команди ND_Input

Рисунок 3.12 - Буфер клавіатури при виконанні команди ND_Input

4. РОЗРОБКА ПРОГРАМИ ДОСЛІДЖЕННЯ РОБОТИ ВСТАНОВЛЕНОГО ДРАЙВЕРА

4.1 ПРИЗНАЧЕННЯ ПРОГРАМИ

Програма дослідження роботи встановленого драйвера консолі призначена для перевірки та дослідження зв'язків DOS через встановлений драйвер з BIOS.

Ця програма за допомогою функцій DOS 08h int 21h , 3Fh int 21h та 0Bh int 21h перевіряє роботу команд INPUT та ND_INPUT драйверу. Також досліджується різниця між ASCII та Binary режимами роботи драйверу при виконанні функції DOS 3Fh int 21h. Аналізуються особливості роботи функцій DOS у режимі відчиненого / зачиненого драйверу консолі. Також в цій программі можливо виконати заміну стандартного переривання int 21h на смодельований обробник, для того, щоб глибше зрозуміти сукупну роботу переривань і їх функцій. Останній пункт виглядає найбільш цікавим, бо розкриває можливості для написаня та встановлення у систему спеціальних переривань та функцій, які не передбачені в операційній системі. Лістінг програми приведений в додатку В.

4.2 РОЗРОБКА СХЕМИ АЛГОРИТМУ ПРОГРАМИ

На рисунку 4.1 зображено алгоритм роботи цієї програми.



Рисунок 4.1 - Структурна схема програми дослідження роботи встановленого драйверу

Тестування роботи драйверу у різних режимах виконується за допомогою цієї програми наступних чином: спочатку (коли драйвер ще знаходиться у ASCII режимі) тестуються усі 3 функції, а саме функція вводу символу з клавіатури 08h, функція перевірки статусу вводу 0Bh (використовує функцію ND_INPUT драйверу), функція вводу з файлу чи пристрою 3Fh, котра з'явилася у розширеній версії DOS(число звертань до драйверу, котре формує операційна система DOS відрізняється для ASCII та Binary режимів).

Після тестування цих трьох функцій драйвер переключається у режим Binary за допомогою функції IOCTL ah = 44h al=01h int 21h і тим самим підготовлюється до наступного етапу тестування функцій DOS.

Знову виконується тестування усіх трьох функцій, після цього драйвер закривається.

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

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

4.3 ОПИС ЗМІННИХ ПРОГРАМИ ТА РОБОТИ МОДУЛІВ ПРОГРАМИ

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

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

4.4 АНАЛІЗ РОБОТИ ПРОГРАМИ ДОСЛІДЖЕННЯ ВСТАНОВЛЕНОГО ДРАЙВЕРА

Головне вікно програми має вигляд, зображений на рисунку 4.2.

Рисунок 4.2 - Головне вікно програми дослідження роботи встановленого драйверу

Пункт 0 дає змогу відкрити CON-драйвер за допомогою функції DOS 3Dh int 21h. Потрібен після виконання пункту 1 або 2.

При виконанні пункту 1 відбувається зачинення дескриптору 0 і клавіатура становиться неактивною.

При виконанні пункту 3 відбувається зачинення дескриптору 1, неможливо щось вивести на екран за допомогою звернень до драйверу консолі. Головне меню буде виводитися в незалежності від стану дескрипторів 0 та 1, тому що воно реалізовано прямим доступом до відео буферу.

Виконання пунктів 1 та 2 виконується за допомогою функції DOS 3Eh int 21h.

За допомогою пунктів 3 та 4 можна змінити поточний статус роботи драйверу консолі: BIN або ASCII.

Функції 5-7 виконують тестування роботи драйверу, за допомогою виклику стандартних функцій DOS, котрі в свою чергу для виконання їх алгоритму скористаються заміщюючим драйвером DOS, котрий за допомогою лічильников і дає змогу користувачу пронаблюдати ход роботи заміщюючого драйверу консолі.

Наведемо декілька екранів роботи програми, по кожній з трьох тестуємих функцій:

Тестування функції 08h:

Рисунок 4.3 - Екран до вводу

Рисунок 4.4 - Екран після вводу

Також було одне звертання до драйвера. А саме функції вводу (лічильник In збільшив своє значення на 1).

Тестування функції 0Bh:

Рисунок 4.5 - Тестування функції ah=0Bh int 21h.

Рисунок 4.6 - Тестування функції ah=0Bh int 21h.

При виконанні цих команд DOS звернувся до драйверу два рази.

(лічильник Nd_in збільшив своє значення на 2).

Тестування функції 3Fh:



Рисунок 4.7 - Тестування функції ah=3Fh int 21h.

Рисунок 4.8 Тестування функції ah=3Fh int 21h.

Тестування функції 3Fh було зроблено, функція звернулася до драйвера 25 разів це незвичайно, бо було введено 24 символів а останній це enter. Бо ця функція працює з системним буфером клавіатури, і ввід у нього може продовжуватись до 127 символів, а функція забере з нього стільки скільки вказав користувач.

Згодом ми можемо знов запросити 5 символів у цієї функції, і побачимо (Рисунок 4.9) що лічильників не видно, а данні введені, і у користувача не було змоги увести данні. І це тому що функція перевірила, чи нема у буфері символів, і якщо є, то ввела не стільки скіки запрошено а скіки є. Крім того вона повернула у викликаючу програму кількість введених символів, про це свідчить напис «Було введено не 5 а 3 символи».

Останній символ має код 10. Це символ який попадає у буфер автоматично при натисканні вводу.

Рисунок 4.9 - Тестування функції ah=3Fh int 21h.

4.5 АНАЛІЗ РОБОТИ ПРОГРАМИ ДОСЛІДЖЕННЯ В РЕЖИМІ ЗАКРИТОГО ДРАЙВЕРУ

Якщо зачинити екран, то зовсім нічого не зміниться. Це не раптово, а тому що вивід на екран усіх повідомлень було зроблено через BIOS. Навіть функція 3Fh ехо на екрані при введенні робить через BIOS.

У разі зачинення дескриптора 0 (клавіатура), при тестуванні функцій: 08h - система зависає, 0Fh - функція одразу нічого не повертає, 0Bh - звертається до драйверу, але незалежно від натискання на клавіші результат негативний, до того ж у цей раз вона звертається до драйверу один раз (рисунки 4.10, 4.11,4.12).

Рисунок 4.10 - Тестування функції 08h



Рисунок 4.11 - Тестування функції 0Bh

.Рисунок 4.12 - Тестування функції 0Fh

4.6 ЗАМІНА ПРОГРАМНОГО ПЕРЕРИВАННЯ int 21h НА СМОДЕЛЬОВАНИЙ ОБРОБНИК

Також ця програма дає можливість підмінити стандартний вектор переривання Int 21h своїм та таким чином мати можливість промоделювати функції MS-DOS (по варіанту завдання 08h, 0Bh, 3Fh).

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

Обробник переривання працює наступним чином: порівнює номер викликаємої функції з номером модельованих, і в разі збігу керування передається до відповідної процедури (однієї з трьох), а потім повертається у зовнішню програму. Якщо це не наша функція то керування передається до старого обробника переривання Int 21h. Блок схема роботи на рисунку 4.13.

Рисунок 4.13 - Структурна схема роботи встановленого обробника переривання Int 21h

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

4.7 РОЗРОБКА ПРОГРАМНОЇМОДЕЛІ ЗАДАНИХ ФУНКЦІЙ int 21h

Рисунок 4.14 - Блок - схема роботи промодельованої функції DOS 08h

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



Рисунок 4.15 - Блок - схема роботи промодельованої функції DOS 0Bh

драйвер програма алгоритм консоль

Функція DOS 0Bh працює без затримки: в залежності від стану внутрішніх змінних драйверу, а саме змінної sav, де драйвер зберігає останній введений символ вона встановлює біт busy, якщо символа у буфері нема, або повертає символ у заголовку запиту ,але не виймає його з буферу - це буде зроблено, коли до драйверу найде запит вводу з кодом 4. Ця функція теж перевіряє не зачинена лі клавіатура. Але до драйверу в разі зачиненості не звертається, як це робила оригінальна функція.



Рисунок 4.16 - Блок - схема роботи промодельованої функції DOS 3Fh

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

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

4.8 РІЗНИЦЯ МІЖ РОБОТОЮ ДРАЙВЕРУ У ASCII ТА BIN РЕЖИМАХ

При використанні функцій базової версії DOS (за моїм варіантом 08h та 0Bh) різниця у роботі не помічається, драйвер у будь-якому випадку виконує ввід з клавіатури.

Різниця між ASCII та BIN режимами помітна у роботі функції розширеної версії DOS - 3Fh. А саме: при вводі 5 символів у ASCII режимі до драйверу надходить 5 запросів (рисунок 4.7, 4.8).

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

Рисунок 4.17 - Робота функції 3Fh в режимі binary

5. РОЗРОБКА ПРОГРАМИ ФОРМУВАННЯ СПИСКУ ДРАЙВЕРІВ

5.1 ПРИЗНАЧЕННЯ ПРОГРАМИ

Програма формування списку драйверів призначена для:

виведення на екран списку драйверів (адреси початку, адреси наступного драйверу, його атрибутів, адреси процедур стратегії та переривання , ім'я драйверу).

видалення заміщуючого драйвера із системи.

Її головне вікно можна побачити на рисунку 5.1, а текст програми приведений у додатку Г.

В DOS драйвери зв'язані у ланцюжок. Заголовок першого драйверу (NUL) знаходиться в області внутрішніх змінних DOS, одразу за Списком _ Списків. Важливо, що по зміщенню 4 - системна файлова таблиця SFT, а по зміщенню 0Ch - дальня адреса драйвера пристрою CON за замовчанням, який встановлений в файлі config.sys. У процесі тестування буде вилучено замінюючий та стандартний драйвери консолі.

Рисунок 5.1 - Головне вікно програми формування списку драйверів

5.2 РОЗРОБКА СХЕМИ АЛГОРИТМУ ПРОГРАМИ

Схема алгоритму програми наведена на рисунку 5.2.

Рисунок 5.2 - Блок-схема алгоритму програми виведення списку драйверів

5.3 АНАЛІЗ РОБОТИ ПРОГРАМИ ФОРМУВАННЯ СПИСКУ ДРАЙВЕРІВ

На рисунку 5.3 наведений список драйверів, встановлених в систему. Як можна побачити, першим у цьому списку йде драйвер пристрою NUL, за ним розташовані усі інші драйвери у порядку, зворотному порядку їх встановлення в систему. Таким чином, останній встановлений драйвер - замінюючий драйвер консолі - стоїть безпосередньо після драйверу NUL. З цього списку видна своєрідна модель організації стандартних драйверів: усі драйвери знаходяться в одному сегменті, заголовки драйверів розташовані один за одним, усі драйвери мають спільну процедуру стратегії.

Рисунок 5.3 - Встановлені в систему драйвери

5.4 РОЗРОБКА РЕЖИМУ ВИДАЛЕННЯ ДРАЙВЕРА З ЛАНЦЮГА ДРАЙВЕРІВ

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

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

Якщо ж тепер видалити обидва драйвери, то виявится помилка і ДОС зависне.



Рисунок 5.4 - Встановлені в систему драйвери до видалення

Рисунок 5.5 - Встановлені в систему драйвери після видалення

ВИСНОВОК

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

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

Було розроблено три програми:

· відлагодження драйвера

· тестування драйвера встановленого у систему

· формування списку встановлених драйверів

Усі три програми були опротестовані, та на основі цих тестів були зроблені висновки по роботі функцій ДОС та драйверу.

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

СПИСОК ЛІТЕРАТУРИ

1.Фролов А.,Фролов Г.Библиотека системного программиста, том 18, MS-DOS для програмиста, М.: Диалог-МИФИ, 1995, 254 с.

2.С.М. Абель Електронний довідник.

3.Франкен Г. MS-DOS… для пользователя: Пер. с нем. - 2-е изд.,перераб. - К.: BHV, 1992. - 513с.

Додаток А

Лістінг програми драйверу

;************************************************************

;******************** Это Драйвер консоли ********************

********* Назначение: заменить стандартный драйвер **************

;*************************************************************

;^^^^^^^^^^^^^^^ ИНСТРУКЦИИ АССЕМБЛЕРУ ^^^^^^^^^^^^^^^^^^^

.286

cseg segment byte public 'CODE'

console proc far

assume cs:cseg

public _dev_strategy, _dev_interrupt ;Передача меток для вызова из Test1

;*************************************************************

;***************** Структуры заголовка запроса ****************

rh struc ;Фиксированная структура заголовка

rh_len db ? ;Длина пакета

rh_unit db ? ;Номер устройства (блоковые)

rh_cmd db ? ;Команда драйвера устройства

rh_status dw ? ;возвращается драйвером

rh_res1 dd ? ;Зарезервировано

rh_res2 dd ? ;Зарезервировано

rh ends

rh0 struc ;Заголовок запроса для команды 0

rh0_rh db size rh dup (?) ;фиксированная часть

rh0_nunits db ? ;Число устройств в группе (блоковые)

rh0_brk_ofs dw ? ;Смещение для конца

rh0_brk_seg dw ? ;Сегмент для конца

rh0_bpb_tbo dw ? ;Смещение указателя массива ВРВ

rh0_bpb_tbs dw ? ;Сегмент указателя массива ВРВ

rh0_dn_itr db ? ;Первый доступный накопитель (DOS 3+)

rh0 ends

rh4 struc ;Заголовок запроса для команды 4

rh4_rh db size rh dup (?) ;фиксированная часть

rh4_media db ? ;Дескриптор носителя из DPB

rh4_buf_ofs dw ? ;Смещение DTA

rh4_buf_seg dw ? ;Сегмент DTA

rh4_count dw ? ;Счетчик передачи байтов

rh4_start dw ? ;Начальный сектор (блоковые)

rh4 ends

rh5 struc ;Заголовок запроса для команды 5

rh5_rh db size rh dup (?) ;Фиксированная часть

rh5_return db ? ;Возвращаемый символ

rh5 ends

rh7 struc ;Заголовок запроса для команды 7

rh7_len db ? ;Длина пакета

rh7_unlt db ? ;Номер устройства (блоковые)

rh7_cmd db ? ;Команда драйвера устройства

rh7_status dw ? ;Возвращается драйвером

rh7_res1 dd ? ;Зарезервировано

rh7_res2 dd ? ;Зарезервировано

rh7 ends

rh8 struc ;Заголовок запроса для команды 8

rh8_rh db size rh dup (?) ;Фиксированная часть

rh8_media db ? ;Дескриптор носителя из DPB

rh8_buf_ofs dw ? ;Смещение DTA

rh8_buf_seg dw ? ;Сегмент DTA

rh8_count dw ? ;Счетчик передачи байтов для символьных

rh8_start dw ? ;Начальный сектор (блоковые)

rh8 ends

rh9 struc ;Заголовок-запроса для команды 9

rh9_rh db size rh dup (?) ;Фиксированная часть

rh9_medla db ? ;Дескриптор носителя из DPB

rh9_buf_of dw ? ;Смещение DTA

rh9_buf_seg dw ? ;Сегмент DTA

rh9_count dw ? ;Счетчик передачи байтов

rh9_start dw ? ;Начальный сектор (блоковые)

rh9 ends

;*************************************************************

;***************************** ОСНОВНАЯ ПРОЦЕДУРА

;*************************************************************

begin:

;*************************************************************

;************** ЗАГОЛОВОК УСТРОЙСТВА ДЛЯ DOS **********

;*************************************************************

next_dev dd -1 ;Других драйверов нет

attribute dw 8003h ;Символьное, ввод, вывод

strategy dw _dev_strategy ;Адрес процедуры СТРАТЕГИЯ

interrupt dw _dev_interrupt ;Адрес процедуры ПРЕРЫВАНИЕ

dev_name db "CON " ;Имя нашего Драйвера Консоли

;*************************************************************

;*********** РАБОЧЕЕ ПРОСТРАНСТВО ДЛЯ ДРАЙВЕРА ********

;*************************************************************

rh_ofs dw ? ;Смещение заголовка запроса

rh_seg dw ? ;Сегмент заголовка запроса

sav db 0 ;Символ, считанный с клавиатуры

Counters label word ;Счетчики выполнения команд

Init dw 0

In_c dw 0

Nd_i dw 0

Outp_c dw 0

Flsh dw 0

Tab label byte ;Таблица счетчиков команд

db "Init |"

db "In |"

db "Nd_i |"

db "Out |"

db "Flsh |"

db "----------"

;*************************************************************

;****************** ПРОЦЕДУРА СТРАТЕГИЯ ******************

;************************************************************

_dev_strategy: ;Первый вызов из DOS

mov cs:rh_seg,es ;Сохранить сегмент

mov cs:rh_ofs,bx ;и смещение заголовка запроса

ret ;Возврат в DOS

;*************************************************************

;************** ПРОЦЕДУРА ПРЕРЫВАНИЕ ********************

;*************************************************************

_dev_interrupt: ;Обработчик прерывания - второй вызов из DOS

;Сохраним состояние регистров

push ax bx ds es bp dx cx si di ;при входе

mov ax,cs:rh_seg ;восстановить регистры ES и ВХ,

mov es,ax ;сохраненные

mov bx,cs:rh_ofs ;процедурой СТРАТЕГИЯ

;Перейти к соответствующей стандартной программе

;для выполнения команды

mov al,es:[bx].rh_cmd ;Команда из заголовка запроса

rol al,1 ;Удвоить для индексирования

lea di,cmdtab ;Адрес таблицы команд

xor ah,ah ;Сбросить регистр АН

add di,ax ;Прибавить индекс к началу

jmp cs:word ptr[di] ;Косвенный переход

;cmdtab - это таблица команд, содержащая 2-байтовый адрес для каждой

;команды. Нужная команда содержится в заголовке запроса.

;Процедура ПРЕРЫВАНИЕ переходит по адресу из таблицы

;к соответствующей стандартной программе.

;Переход по команде, переданной в заголовке запроса

cmdtab label byte ;* - символьное устройство

dw INITIALIZATION ;Инициализация

dw MEDIA_CHECK ;Контроль носителя (блоковые)

dw GET_BPB ;Получение ВРВ

dw IOCTL_INPUT ;IOCTL ввод

dw INPUT ;Ввод

dw ND_INPUT ;Неразрушающий ввод

dw INPUT_STATUS ;Состояние ввода

dw INPUT_FLUSH ;Очистка ввода

dw OUTPUT ;Вывод

dw OUTPUT_VERIFY ;Вывод с контролем

dw OUTPUT_STATUS ;Состояние вывода

dw OUTPUT_FLUSH ;Очистка вывода

dw IOCTL_OUT ;IOCTL вывод

dw OPEN ;Открытие устройства

dw CLOSE ;Закрытие устройства

dw REMOVABLE ;Сменный носитель

dw OUTPUT_BUSY ;Вывод до занятости

;*************************************************************

;*************** ЛОКАЛЬНЫЕ ПРОЦЕДУРЫ ******************

;*************************************************************

;*************** Вывод таблицы счетчиков **********************

CT_OUT proc near

mov ax, 0b800h ;Адрес нулевой видеостраницы

mov es, ax

mov bx, 142 ;Начало вывода

lea si, Tab ;Адрес выводимой таблицы

add si, 6 ;Установка в нужную позицию записи

xor di, di ;Номер выводимого счетчика

mov cx, 5 ;кол-во чисел для перевода в строку

Col_C:

mov dx, cs:Counters[di] ;Запись счетчика в dx

shl dx, 4

mov bp, cx

mov cx, 3 ;Кол-во символов в 16-с\с

Razl:

rol dx, 4 ;Сначала взять старшую цифру в 16-с\с

mov al, 1111b ;Маска

and al, dl ;Выделение последней (старшей) цифры

add al, 30h ;Перевод цифры в символ

cmp al, 3ah ;Если цифра в диапазоне букв A-F,

jb Out_c ;то необходимо изменить смещение

add al, 7

Out_C:

mov cs:[si], al ;Записать цифру в строку вывода

inc si ;

loop Razl ;Повторение 4 раза

mov cx, bp

add di, 2

add si, 7 ;Переход на нужное поле для записи

loop Col_C ;

;Вывод таблицы через видеобуфер

mov cx, 54 ;Колличество выводимых соиволов

lea si, Tab

Out_T:

mov al, cs:[si]

mov ah, 01100111b ;Цвет символа и фона

mov es:[bx], ax

add bx, 2

inc si

cmp byte ptr cs:[si], "|"

jne Next1

add bx, 142

inc si

Next1:

loop Out_T

ret

CT_OUT endp

;*************************************************************

;****************** ОБРАБОТКА КОМАНД DOS ***************

;*************************************************************

;************ Команда 0 : Инициализация ******************

initialization:

inc cs:Init

call initial ;Вывести сообщение

lea ax,initial ;Установить адрес конца

mov es:[bx].rh0_brk_ofs,ax ;Сохранить смещение

mov es:[bx].rh0_brk_seg,cs ;Сохранить сегмент

jmp done ;Установить СДЕЛАНО и выйти

;**************** Команда 1 : Контроль носителя *****************

media_check:

jmp done ;Установить бит СДЕЛАНО и выйти

;**************** Команда 2 : Получение ВРВ *******************

get_bpb:

jmp done ;Установить бит СДЕЛАНО и выйти

;**************** Команда 3 : Ввод IOCTL *********************

IOCTL_input:

jmp _unknown ;Установить бит ОШИБКА и выйти

;**************** Команда 4 : Ввод ****************************

input:

inc cs:In_c

mov cx,es:[bx].rh4_count ;Загрузить счетчик ввода

mov di,es:[bx].rh4_buf_ofs ;Загрузить смещение

mov ax,es:[bx].rh4_buf_seg ;Загрузить сегмент

mov es,ax ;Передать сегмент в ES

read1:

xor ax, ax ;Сбросить АХ

xchg al,cs:sav ;Взять сохраненный символ

cmp al,0 ;0н равен 0 ?

jne read3 ;Нет - возвратить его

read2:

xor ah,ah ;0бслуживание считывания

int 16h ;Вызов клавиатуры BIOS

cmp ax,0 ;Клавиша равна 0 ?

jz read2 ;Да, взять другой символ

cmp al,0 ;Это расширенная клавиша ?

jne read3 ;Нет-возвратить ее

mov cs:sav,ah ;Сохраноть скэн-код

read3:

mov es:[di],al ;Сохранить значение в буфере

inc di ;Продвинуть указатель

loop read1 ;Продолжать до счетчика = 0

mov ax,cs:rh_seg ;восстановить регистр ES

mov es,ax ;из rh_seg

mov bx,cs:rh_ofs ;Восстановить регистр ВХ

jmp done ;Установить бит СДЕЛАНО и выйти

;**************** Команда 5 : Неразрушающий ввод **************

nd_input:

inc cs:Nd_i

mov al,cs:sav ;Взять сохраненный символ

cmp al,0 ;0н равен 0?

jne nd1 ;Нет - возвратить его в DOS

mov ah,1 ;Обслуживание - контроль состояния

int 16h ;Вызов клавиатуры BIOS

jnz NotBusy ;При ZF = 0 символ в буфере етсь

jmp busy ;При ZF = 1 символа в буфере нет

NotBusy:

cmp ax,0 ;Клавиша - 0?

jne nd1 ;Нет - возвратить ее в DOS

xor ah,ah ;Обслуживание - считывание

int 16h ;Выэов клавиатуры BIOS

jmp nd_input ;Проверять вновь

nd1:

mov es:[bx].rh5_return,al ;возвратить клавишу в DOS

jmp done ;Остановить бит СДЕЛАНО и выйти

;***************** команда 6 : Состояние ввода *****************

input_status:

jmp done ;Установить бит СДЕЛАНО и выйти

;**************** Команда 7 : Очистка ввода *********************

input_flush:

inc cs:Flsh

mov cs:sav,0 ;Сбросить сохраненный символ

If_1:

mov ah,1 ;Обслуживание - контроль состояния

int 16h ;Вызов клавиатуры BIOS

jz done ;При ZF = 1 буфер пустой

xor ah,ah ;Обслуживание - считывание

int 16h ;Вызов клавиатуры BIOS

jmp If_1 ;Повторять до опустошения

;**************** Команда 8 : Вывод ****************************

output:

inc cs:Outp_c

mov cx,es:[bx].rh8_count ;Взять счетчик вывода

mov di,es:[bx].rh8_buf_ofs ;Загрузить смещение

mov ax,es:[bx].rh8_buf_seg ;Загрузить сегмент

mov es,ax ;в регистр ES

xor bx,bx ;Сбросить ВХ

out1:

mov al,es:[di] ;Взять выводимый символ

inc di ;Продвинуть указатель

mov ah,0eh ;Обслуживание - запись как TTY

int 10h ;Вызов экрана BIOS

loop out1 ;Повторять до исчерпания счетчика

mov ax,cs:rh_seg ;Восстановить в регистре ES

mov es,ax ;сегмент заголовка запроса

mov bx,cs:rh_ofs ;восстановить регистр ВХ

jmp done ;Установить бит СДЕЛАНО и выйти

;Команда 9 : Вывод с контролем

output_verify:

jmp output ;Аналогично команде вывода

;Команда 10 : Состояние вывода

output_status:

jmp done ;Установить бит СДЕЛАНО и выйти

;Команда 11 : Очистка вывода

output_flush:

jmp done ;Установить бит СДЕЛАНО и выйти

;Команда 12 : IOCTL-вывод

ioctl_out:

jmp _unknown ;Установить бит ОШИБКА и выйти

;Команда 13 : Открытие

open:

jmp done ;Установить бит СДЕЛАНО и выйти

;Команда 14 : Закрытие

close:

jmp done ;Остановить бит СДЕЛАНО и выйти

;Команда 15 : Сменный носитель