Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Потрібно виконати лише на даний час↑ Стр 1 из 19Следующая ⇒ Содержание книги
Поиск на нашем сайте
Студенти 4 – го курсу методичний посібник допоможе Вам у вирішенні модульних контрольних робіт, підготовці до екзамену, та лабораторних занять. Потрібно виконати лише на даний час Тести модульного контролю 1 (МКР1) І варіант ІІ варіант ВСТУП Розділ 1. Основні концепції операційних систем..................................... 6 1. 1. Поняття операційної системи та її призначення................ 7 1. 2. Історія розвитку операційних систем.................................. 9 1. 3. Класифікація операційних систем ……………………….10 1. 4. Основні функції операційної системи…………………...13 1. 5. Мережна підтримка…………………………………………..13 1. 6. Безпека даних………………………………………………….14 Розділ 2 Архітектура операційних систем…………………………… 15 2. 1. Означення архітектури операційних систем ………….15 Ядро системи та системне програмне забезпечення..16 Взаємодія операційної системи та апаратного забезпечення ………………………………………………….20 Взаємодія операційної системи та прикладних програм …………………………………………………………. 23 2. 5. Архітектура UNIX i Linux ……………………………………25 2. 6. Архітектура Windows XP ………………………………… 29 Розділ 3 Фізична організація і характеристики файлових cистем …………………………………………………………….. 36 3. 1. Базові відомості про дискові пристрої………………..36 3. 2. Ефективність операцій доступу до диска…………….37 3. 3. Фізична організація розділів на жорсткому диску….39 3. 4. Продуктивність файлових систем…………………… 48 3. 5. Надійність файлових систем…………………………… 58 3. 6. Журнальні файлові системи…………………………… 64 Розділ 4 Реалізація файлових систем................................................67 4. 1. Інтерфейс віртуальної файлової системи VFS...........67 4. 2. Загальна організація VFS................................................68 4. 3. Файлова система ext2fs..................................................75 4. 4. Особливості файлової системи ext3fs.........................77 4. 5. Файлова система /ргос....................................................78 4. 6. Файлові системи лінії FAT..............................................79 4. 7. Розміщення інформації на диску..................................82 4. 8. Стискання даних............................................................. 86 4.9. Особливості кешування у Windows XP.........................87 4.10. Системний реєстр Windows XP....................................88 Вступ Методичний посібник містить повний і систематизований виклад фундаментальних концепцій і практичних рішень, що лежать в основі сучасних операційних систем. Головною характеристикою посібника є його практична спрямованість. Зокрема, для вивчення були ретельно відібрані теоретичні концепції, які застосовуються у сучасних операційних системах, при цьому кожна з них підкріплюється практичними прикладами, що розкривають особливості організації UNIX/Linux i Windows XP/Windows Server 2003. Посібник складається з 4 розділів. У перших двох розділах наведено базові означення курсу, розглянуто основні функції сучасних операційних систем, введено поняття архітектури операційної системи, описано архітектурні особливості Linux i Windows XP. Інформація про Linux базується на останніх версіях ядра (2.4-2.6), в роботі над прикладами переважно використана система Red Hat Linux 7.2. Більшість описаних системних викликів відповідає стандарту POSIX, тому цей матеріал також може бути використаний під час вивчення інших версій UNIX. Цей методичний посібник відрізняється від інших тим, що в ньому наведено детальний опис програмних інтерфейсів, необхідних для одержання доступу до відповідних засобів операційних систем із прикладних програм. Описано особливості використання більш ніж 250 системних викликів UNIX/Linux i функцій Win32 API, наведено численні приклади програмного коду, що застосовує ці виклики й функції. Програмний код використовує тільки стандартні засоби ANSI C та програмних інтерфейсів операційних систем; для компіляції цього коду може бути використаний будь-який засіб розробки, що підтримує відповідні стандарти (для розробки коду під Linux автор застосовував gcc, зручним безкоштовним засобом розробки під Windows XP є Microsoft Visual C++ Toolkit y поєднанні з Microsoft Platform SDK). Практична спрямованість книги робить її корисною і для фахівців. Наприклад, нею можуть користуватися розробники програмного забезпечення та системні адміністратори для підвищення своєї кваліфікації в галузі операційних систем.
Розділ 1 Тема: Основні концепції операційних систем · Поняття операційної системи та її призначення · Історія розвитку операційних систем · Класифікація операційних систем · Основні функції операційної системи · Мережна підтримка · Безпека даних
Поняття операційної системи, ії призначення та функції Причиною появи операційних систем була необхідність створення зручних у використанні комп'ютерних систем (під комп'ютерною системою будемо розуміти сукупність апаратного і програмного забезпечення комп'ютера). Комп'ютерні системи від самого початку розроблялися для розв'язання практичних задач користувачів. Оскільки робити це за допомогою лише апаратного забезпечення виявилося складно, були створені прикладні програми. Для таких програм знадобилися загальні операції керування апаратним забезпеченням, розподілу апаратних ресурсів тощо. Ці операції згрупували в рамках окремого рівня програмного забезпечення, який і стали називати операційною системою. Далі можливості операційних систем вийшли далеко за межі базового набору операцій, необхідних прикладним програмам, але проміжне становище таких систем між прикладними програмами й апаратним забезпеченням залишилося незмінним. Можна дати таке означення операційної системи. Операційна система (ОС) — це програмне забезпечення, що реалізує зв'язок між прикладними програмами й апаратними засобами комп'ютера. Призначення операційної системи Операційні системи забезпечують, по-перше, зручність використання комп'ютерної системи, по-друге, ефективність і надійність її роботи. Перша функція властива ОС як розширеній машині, друга - ОС як розподілювача апаратних ресурсів.
Операційна система як розподілювач ресурсів Операційна система має ефективно розподіляти ресурси. Під ресурсами розуміють процесорний час, дисковий простір, пам'ять, засоби доступу до зовнішніх пристроїв. Операційна система виступає в ролі менеджера цих ресурсів і надає їх прикладним програмам на вимогу. Розрізняють два основні види розподілу ресурсів. У разі просторового розподілу ресурс доступний декільком споживачам одночасно, при цьому кожен із них може користуватися частиною ресурсу (так розподіляється пам'ять). У разі часового розподілу система ставить споживачів у чергу і згідно з нею надає їм змогу користуватися всім ресурсом обмежений час (так розподіляється процесор в однопроцесорних системах). При розподілі ресурсів ОС розв'язує можливі конфлікти, запобігає несанкціонованому доступу програм до тих ресурсів, на які вони не мають прав, забезпечує ефективну роботу комп'ютерної системи.
Функціональні компоненти операційних систем Операційну систему можна розглядати як сукупність функціональних компонентів, кожен з яких відповідає за реалізацію певної функції системи. У цьому розділі описані найважливіші функції сучасних ОС і компоненти, що їх реалізують. Спосіб побудови системи зі складових частин та їхній взаємозв'язок визначає архітектура операційної системи. Підходи до реалізації архітектури ОС будуть розглянуті в розділі 2.
Керування пам'яттю Під час виконання програмного коду процесор бере інструкції й дані з оперативної (основної) пам'яті комп'ютера. При цьому така пам'ять відображається у вигляді масиву байтів, кожен з яких має адресу. Як уже згадувалося, основна пам'ять є одним із видів ресурсів, розподілюваних між процесами. ОС відповідає за виділення пам'яті під захищений адресний простір процесу і за вивільнення пам'яті після того, як виконання процесу буде завершено. Обсяг пам'яті, доступний процесу, може змінюватися в ході виконання, у цьому разі говорять про динамічний розподіл пам'яті. ОС повинна забезпечувати можливість виконання програм, які окремо або в сукупності перевищують за обсягом доступну основну пам'ять. Для цього в ній має бути реалізована технологія віртуальної пам'яті. Така технологія дає можливість розміщувати в основній пам'яті тільки ті інструкції й дані процесу, які потрібні в поточний момент часу, при цьому вміст іншої частини адресного простору зберігається на диску.
Мережна підтримка Мережні системи Сучасні операційні системи пристосовані до роботи в мережі, їх називають мережними операційними системами [29]. Засоби мережної підтримки дають ОС можливість: ♦ надавати локальні ресурси (дисковий простір, принтери тощо) у загальне користування через мережу, тобто функціонувати як сервер; ♦ звертатися до ресурсів інших комп'ютерів через мережу, тобто функціонувати як клієнт. Реалізація функціональності сервера і клієнта базується на транспортних засобах, відповідальних за передачу даних між комп'ютерами відповідно до правил, обумовлених мережними протоколами. Розподілені системи Мережні ОС не приховують від користувача наявність мережі, мережна підтримка в них не визначає структуру системи, а збагачує її додатковими можливостями. Є також розподілені ОС [6, 45], які дають змогу об'єднати ресурси декількох комп'ютерів у розподілену систему. Вона виглядає для користувача як один комп'ютер з декількома процесорами, що працюють паралельно. Розподілені та багатопроцесорні системи є двома основними категоріями ОС, які використовують декілька процесорів. Вони мають багато спільного й будуть розглянуті в розділі 20.
Безпека даних Під безпекою даних в ОС розуміють забезпечення надійності системи (захисту даних від втрати у разі збоїв) і захист даних від несанкціонованого доступу (випадкового чи навмисного). Для захисту від несанкціонованого доступу ОС має забезпечувати наявність засобів аутентифікації користувачів (такі засоби дають змогу з'ясувати, чи є користувач тим, за кого себе видає; зазвичай для цього використовують систему паролів) та їхньої авторизація (дозволяють перевірити права користувача, що пройшов аутентифікацію, на виконання певної операції). Інтерфейс користувача Розрізняють два типи засобів взаємодії користувача з ОС: командний інтерпретатор (shell) i графічний інтерфейс користувача (GUI). Командний інтерпретатор дає змогу користувачам взаємодіяти з ОС, використовуючи спеціальну командну мову (інтерактивно або через запуск на виконання командних файлів). Команди такої мови змушують ОС виконувати певні дії (наприклад, запускати програми, працювати із файлами). Графічний інтерфейс користувача надає йому можливість взаємодіяти з ОС, відкриваючи вікна і виконуючи команди за допомогою меню або кнопок. Підходи до реалізації графічного інтерфейсу доволі різноманітні: наприклад, у Windows-системах засоби його підтримки вбудовані в систему, а в UNIX вони є зовнішніми для системи і спираються на стандартні засоби керування введенням-виведенням.
Розділ 2 Механізми і політика В ОС насамперед необхідно виділити набір фундаментальних можливостей, які надають її компоненти; ці базові можливості становлять механізм (mechanism). 3 іншого боку, необхідно приймати рішення щодо використання зазначених можливостей; такі рішення визначають політику (policy). Отже, механізм показує, що реалізовано компонентом, а політика - як це можна використати. Коли за реалізацію механізму і політики відповідають різні компоненти (механізм відокремлений від політики), спрощується розробка системи і підвищується її гнучкість. Компонентам, що реалізують механізм, не повинна бути доступна інформація про причини та цілі його застосування; усе, що потрібно від них, - це виконувати призначену їм роботу. Для таких компонентів використовують термін «вільні від політики» (policy-free). Компоненти, відповідальні за політику, мають оперувати вільними від неї компонентами як будівельними блоками, для них недоступна інформація про деталі реалізації механізму. Прикладом відокремлення механізму від політики є керування введенням-виведенням. Базові механізми доступу до периферійних пристроїв реалізують драйвери. Політику використання цих механізмів задає програмне забезпечення, що здійснює введення-виведення. Монолітні системи ОС, у яких усі базові функції сконцентровані в ядрі, називають монолітними системами. У разі реалізації монолітного ядра ОС стає продуктивнішою (процесор не перемикається між режимами під час взаємодії між її компонентами), але менш надійною (весь її код виконується у привілейованому режимі, і помилка в кожному з компонентів є критичною). Монолітність ядра не означає, що всі його компоненти мають постійно перебувати у пам'яті. Сучасні ОС дають можливість динамічно розміщувати в адресному просторі ядра фрагменти коду (модулі ядра). Реалізація модулів ядра дає можливість також досягти його розширюваності (для додання нової функціональності досить розробити і завантажити у пам'ять відповідний модуль).
Багаторівневі системи Компоненти багаторівневих ОС утворюють ієрархію рівнів (шарів, layers), кожен з яких спирається на функції попереднього рівня. Найнижчий рівень безпосередньо взаємодіє з апаратним забезпеченням, на найвищому рівні реалізуються системні виклики. У традиційних багаторівневих ОС передача керування з верхнього рівня на нижній реалізується як системний виклик. Верхній рівень повинен мати права на виконання цього виклику, перевірка цих прав виконується за підтримки апаратного забезпечення. Прикладом такої системи є ОС Multics, розроблена в 60-ті роки. Практичне застосування цього підходу сьогодні обмежене через низьку продуктивність. Рівні можуть виділятися й у монолітному ядрі; у такому разі вони підтримуються програмно і спричиняють спрощення реалізації системи. У монолітному ядрі визначають рівні, перелічені нижче. · Засоби абстрагування від устаткування, які взаємодіють із апаратним забезпеченням безпосередньо, звільняючи від реалізації такої взаємодії інші компоненти системи. · Базові засоби ядра, які відповідають за найфундаментальніші, найпростіші дії ядра, такі як запис блоку даних на диск. За допомогою цих засобів виконуються вказівки верхніх рівнів, пов'язані з керуванням ресурсами. · Засоби керування ресурсами (або менеджери ресурсів), що реалізують основні функції ОС (керування процесами, пам'яттю, введенням-виведенням тощо). На цьому рівні приймаються найважливіші рішення з керування ресурсами, які виконуються з використанням базових засобів ядра. · Інтерфейс системних викликів, який служить для реалізації зв'язку із системним і прикладним програмним забезпеченням. Розмежування базових засобів ядра і менеджерів ресурсів відповідає відокремленню механізмів від політики в архітектурі системи. Базові засоби ядра визначають механізми функціонування системи, менеджери ресурсів реалізують політику.
Системи з мікроядром Один із напрямів розвитку сучасних ОС полягає в тому, що у привілейованому режимі реалізована невелика частка функцій ядра, які є мікроядром (microkernel). Інші функції ОС виконуються процесами режиму користувача (серверними процесами, серверами). Сервери можуть відповідати за підтримку файлової системи, за роботу із процесами, пам'яттю тощо. Мікроядро здійснює зв'язок між компонентами системи і виконує базовий розподіл ресурсів. Щоб виконати системний виклик, процес (клієнтський процес, клієнт) звертається до мікроядра. Мікроядро посилає серверу запит, сервер виконує роботу і пересилає відповідь назад, а мікроядро переправляє його клієнтові (рис. 2.1). Клієнтами можуть бути не лише процеси користувача, а й інші модулі ОС. Перевагами мікроядрового підходу є: · невеликі розміри мікроядра, що спрощує його розробку й налагодження; · висока надійність системи, внаслідок того що сервери працюють у режимі користувача й у них немає прямого доступу до апаратного забезпечення; · більша гнучкість і розширюваність системи (непотрібні компоненти не займають місця в пам'яті, розширення функціональності системи зводиться до додавання в неї нового сервера); · можливість адаптації до умов мережі (спосіб обміну даними між клієнтом і сервером не залежить від того, зв'язані вони мережею чи перебувають на одному комп'ютері).
Головним недоліком мікроядрового підходу є зниження продуктивності. Замість двох перемикань режиму процесора у разі системного виклику відбувається чотири (два — під час обміну між клієнтом і мікроядром, два — між сервером та мікроядром). Зазначений недолік є, швидше, теоретичним, на практиці продуктивність і надійність мікроядра залежать насамперед від якості його реалізації. Так, в ОС QNX мікроядро займає кілька кілобайтів пам'яті й забезпечує мінімальний набір функцій, при цьому система за продуктивністю відповідає ОС реального часу.
Концепція віртуальних машин У системах віртуальних машин програмним шляхом створюють копії апаратного забезпечення (відбувається його емуляція). Ці копії (віртуальні машини) працюють паралельно, на кожній із них функціонує програмне забезпечення, з яким взаємодіють прикладні програми і користувачі. Уперше концепція віртуальних машин була реалізована в 70-ті роки в операційній системі VM фірми IBM. У СРСР варіант цієї системи (VM/370) був широко розповсюджений у 80-ті роки і мав назву Система віртуальних машин ЄС ЕОМ (СВМ ЄС). Розглянемо архітектуру цієї ОС [8,4], що показана на рис. 2.2. Ядро системи, яке називалося монітором віртуальних машин (VM Monitor, МВМ), виконувалося на фізичній машині, безпосередньо взаємодіючи з її апаратним забезпеченням. Монітор реалізовував набір віртуальних машин (ВМ). Кожна ВМ була точною копією апаратного забезпечення, на ній могла бути запущена будь-яка ОС, розроблена для цієї архітектури. Найчастіше на ВМ встановлювали спеціальну однокористувацьку ОС CMS (підсистема діалогової обробки, ПДО). На різних ВМ могли одночасно функціонувати різні ОС. Коли програма, написана для ПДО, виконувала системний виклик, його перехоплювала копія ПДО, запущена на відповідній віртуальній машині. Потім ПДО виконувала відповідні апаратні інструкції, наприклад інструкції введення-виведення для читання диска. Ці інструкції перехоплював МВМ і перетворював їх на апаратні інструкції фізичної машини. Віртуальні машини спільно використовували ресурси реального комп'ютера; наприклад, дисковий простір розподілявся між ними у вигляді віртуальних дисків, названих мінідисками. ОС, запущена у ВМ, використовувала мінідиски так само, як фізичні диски. Сьогодні концепція віртуальних машин застосовується і в прикладному програмному забезпеченні; опис відповідних рішень (програмних емуляторів апаратного забезпечення, технології керованого коду) можна знайти на сайті супроводу. Із означення ОС випливає, що вона реалізує зв'язок між апаратним забезпеченням комп'ютера (через інтерфейс апаратного забезпечення) і програмами користувача (через інтерфейс прикладного програмування). У цьому розділі розглянуто особливості реалізації та використання цих інтерфейсів. Програмна сумісність Дотепер ми розглядали виконання в ОС програм, розроблених спеціально для неї. Іноді буває необхідно виконати в середовищі ОС програми, розроблені для інших ОС і, можливо, для іншої апаратної архітектури. У цьому разі виникає проблема програмної сумісності. Програмна сумісність означає можливість виконувати в середовищі однієї операційної системи програми, розроблені для іншої ОС. Розрізняють сумісність на рівні вихідних текстів (можливість перенесення вихідних текстів) та бінарну сумісність (можливість перенесення виконуваного коду). Для сумісності на рівні вихідних текстів необхідно, щоб для всіх ОС існувала реалізація компілятора мови і API, що його використовує програма. Сьогодні таку сумісність забезпечує стандартизація розробки програмного забезпечення, а саме: · наявність стандарту на мови програмування (насамперед на С і C++) і стандартних компіляторів; · наявність стандарту на інтерфейс операційної системи (API). Робота зі стандартизації інтерфейсу операційних систем відбувається у рамках проекту POSIX (Portable Operating System Interface). Найбільш важливим стандартом є POSIX 1003.1 [3], який описує набір бібліотечних процедур (таких, як відкриття файла, створення нового процесу тощо), котрі мають бути реалізовані в системі. Цей процес стандартизації триває дотепер, останньою редакцією стандарту є базова специфікація Open Group/IEEE [103]. Зазначені стандарти відображають традиційний набір засобів, реалізованих в UNIX-сумісних системах. Завдання забезпечення бінарної сумісності виникає тоді, коли потрібно запустити на виконання файл прикладної програми у середовищі іншої операційної системи. Таке завдання значно складніше в реалізації, найпоширеніший підхід до його розв'язання - емуляція середовища виконання. У цьому разі програма запускається під керуванням іншої програми — емулятора, який забезпечує динамічне перетворення інструкцій програми в інструкції потрібної архітектури. Прикладом такого емулятора є програма wine, яка дає можливість запускати програми, розроблені для Win32 API, y середовищі Linux через емуляцію функцій Win32 API системними викликами Linux.
Архітектура: UNIX i Linux Базова архітектура UNIX UNIX є прикладом досить простої архітектури ОС. Більша частина функціональності цієї системи міститься в ядрі, ядро спілкується із прикладними програмами за допомогою системних викликів. Базова структура класичного ядра UNIX зображена на рис. 2.3 (див., наприклад, [3, 9]).
Система складається із трьох основних компонентів: підсистеми керування процесами, файлової підсистеми та підсистеми введення-виведення. Підсистема керування процесами контролює створення та вилучення процесів, розподілення системних ресурсів між ними, міжпроцесову взаємодію, керування пам'яттю. Файлова підсистема забезпечує єдиний інтерфейс доступу до даних, розташованих на дискових накопичувачах, і до периферійних пристроїв. Такий інтерфейс є однією з найважливіших особливостей UNIX. Одні й ті самі системні виклики використовують як для обміну даними із диском, так і для виведення на термінал або принтер (програма працює із принтером так само, як із файлом). При цьому файлова система переадресовує запити відповідним модулям підсистеми введення-виведення, а ті — безпосередньо периферійним пристроям. Крім того, файлова підсистема контролює права доступу до файлів, які значною мірою визначають привілеї користувача в системі. Підсистема введення-виведення виконує запити файлової підсистеми, взаємодіючи з драйверами пристроїв. В UNIX розрізняють два типи пристроїв: символьні (наприклад, принтер) і блокові (наприклад, жорсткий диск). Основна відмінність між ними полягає в тому, що блоковий пристрій допускає прямий доступ. Для підвищення продуктивності роботи із блоковими пристроями використовують буферний кеш - ділянку пам'яті, у якій зберігаються дані, зчитані з диска останніми. Під час наступних звертань до цих даних вони можуть бути отримані з кеша. Сучасні UNIX-системи дещо відрізняються за своєю архітектурою. · У них виділено окремий менеджер пам'яті, відповідальний за підтримку віртуальної пам'яті. · Стандартом для реалізації інтерфейсу файлової системи є віртуальна файлова система, що абстрагує цей інтерфейс і дає змогу організувати підтримку різних типів файлових систем. · У цих системах підтримується багатопроцесорна обробка, а також багатопотоковість. Базові архітектурні рішення, такі як доступ до всіх пристроїв введення-виведення через інтерфейс файлової системи або організація системних викликів, залишаються незмінними в усіх реалізаціях UNIX.
Архітектура Linux В ОС Linux можна виділити три основні частини: · ядро, яке реалізує основні функції ОС (керування процесами, пам'яттю, введенням-виведенням тощо); · системні бібліотеки, що визначають стандартний набір функцій для використання у застосуваннях (виконання таких функцій не потребує переходу в привілейований режим); · системні утиліти (прикладні програми, які виконують спеціалізовані задачі). Модулі ядра Ядро Linux дає можливість на вимогу завантажувати у пам'ять і вивантажувати з неї окремі секції коду. Такі секції називають модулями ядра (kernel modules) [30] і виконують у привілейованому режимі. Модулі ядра надають низку переваг. ♦ Код модулів може завантажуватися в пам'ять у процесі роботи системи, що спрощує налагодження компонентів ядра, насамперед драйверів. ♦ З'являється можливість змінювати набір компонентів ядра під час виконання: ті з них, які в цей момент не використовуються, можна не завантажувати у пам'ять. ♦ Модулі є винятком із правила, за яким код, що розширює функції ядра, відповідно до ліцензії Linux має бути відкритим. Це дає змогу виробникам апаратного забезпечення розробляти драйвери під Linux, навіть якщо не заплановано надавати доступ до їхнього вихідного коду.
Застосування користувача Застосування користувача в Linux використовують функції із системних бібліотек і через них взаємодіють із ядром за допомогою системних викликів.
Компоненти режиму ядра У традиційному розумінні ядро ОС містить усі компоненти привілейованого режиму, однак у Windows XP поняття ядра закріплене тільки за одним із цих компонентів. Рівень абстрагування від устаткування У Windows XP реалізовано рівень абстрагування від устаткування (у цій системі його називають HAL, hardware abstraction layer). Для різних апаратних конфігурацій фірма Microsoft або сторонні розробники можуть постачати різні реалізації HAL. Хоча код HAL є дуже ефективним, його використання може знижувати продуктивність застосувань мультимедіа. У такому разі використовують спеціальний пакет DirectX, який дає змогу прикладним програмам звертатися безпосередньо до апаратного забезпечення, обминаючи HAL та інші рівні системи.
Ядро Ядро Windows XP відповідає за базові операції системи. До його основних функцій належать: · перемикання контексту, збереження і відновлення стану потоків; · планування виконання потоків; · реалізація засобів підтримки апаратного забезпечення, складніших за засоби HAL (наприклад, передача керування оброблювачам переривань). Ядро Windows XP відповідає базовим службам ОС і надає набір механізмів для реалізації політики керування ресурсами. Основним завданням ядра є якомога ефективніше завантаження процесорів системи. Ядро постійно перебуває в пам'яті, послідовність виконання його інструкцій може порушити тільки переривання (під час виконання коду ядра багатозадачність не підтримується). Для прискорення роботи ядро ніколи не перевіряє правильність параметрів, переданих під час виклику його функцій. Windows XP не можна віднести до якогось певного класу ОС. Наприклад, хоча за функціональністю ядро системи відповідає поняттю мікроядра, для самої ОС не характерна класична мікроядрова архітектура, оскільки у привілейованому режимі виконуються й інші її компоненти.
Виконавча система Виконавча система (ВС) Windows XP (Windows XP Executive) - це набір компонентів, відповідальних за найважливіші служби ОС (керування пам'яттю, процесами і потоками, введенням-виведенням тощо). Компонентами ВС є передусім базові засоби підтримки. Ці засоби використовують у всій системі. ♦ Менеджер об'єктів — відповідає за розподіл ресурсів у системі, підтримуючи їхнє універсальне подання через об'єкти. ♦ Засіб локального виклику процедур (LPC) — забезпечує механізм зв'язку між процесами і підсистемами на одному комп'ютері. Інші компоненти ВС реалізують найважливіші служби Windows XP. Зупинимося на деяких із них.
Менеджер процесів і потоків — створює та завершує процеси і потоки, а також розподіляє для них ресурси. Менеджер віртуальної пам'яті - реалізує керування пам'яттю в системі, насамперед підтримку віртуальної пам'яті. Менеджер введення-виведення - керує периферійними пристроями, надаючи іншим компонентам апаратно-незалежні засоби введення-виведення. Цей менеджер реалізує єдиний інтерфейс для драйверів пристроїв. ♦ Менеджер кеша — керує кешуванням для системи введення-виведення. Часто використовувані блоки диска тимчасово зберігаються в пам'яті, наступні операції введення-виведення звертаються до цієї пам'яті, внаслідок чого підвищується продуктивність. ♦ Менеджер конфігурації - відповідає за підтримку роботи із системним реєстром (registry) - ієрархічно організованим сховищем інформації про налаштування системи і прикладних програм. ♦ Довідковий монітор захисту — забезпечує політику безпеки на ізольованому комп'ютері, тобто захищає системні ресурси.
Драйвери пристроїв У Windows ХР драйвери не обов'язково пов'язані з апаратними пристроями. Застосування, якому потрібні засоби, доступні в режимі ядра, завжди варто оформляти як драйвер. Це пов'язане з тим, що для зовнішніх розробників режим ядра доступний тільки з коду драйверів. Докладніше реалізацію драйверів Windows XP буде розглянуто в розділі 15. Віконна і графічна підсистеми Віконна і графічна підсистеми відповідають за інтерфейс користувача - роботу з вікнами, елементами керування і графічним виведенням. · Менеджер вікон — реалізує високорівневі функції. Він керує віконним виведенням, обробляє введення з клавіатури або миші й передає застосуванням повідомлення користувача. · Інтерфейс графічних пристроїв (Graphical Device Interface, GDI) — складається з набору базових операцій графічного виведення, які не залежать від конкретного пристрою (креслення ліній, відображення тексту тощо). · Драйвери графічних пристроїв (відеокарт, принтерів тощо) — відповідають за взаємодію з контролерами цих пристроїв. Під час створення вікон або елементів керування запит надходить до менеджера вікон, який для виконання базових графічних операцій звертається до GDI. Потім запит передається драйверу пристрою, затим — апаратному забезпеченню через HAL. Підсистеми середовища Підсистеми середовища надають застосуванням користувача доступ до служб операційної системи, реалізуючи відповідний API. Ми зупинимося на двох підсистемах середовища: Win32 і POSIX. Підсистема Win32, яка реалізує Win32 API, є обов'язковим компонентом Windows ХР. До неї входять такі компоненти: ♦ процес підсистеми Win32 (csrss.exe), що відповідає, зокрема, за реалізацію текстового (консольного) введення-виведення, створення і знищення процесів та потоків; ♦ бібліотеки підсистеми Win32, які надають прикладним програмам функції Win32 API. Найчастіше використовують бібліотеки gdi32.dll (низькорівневі графічні функції, незалежні від пристрою), user32.dll (функції інтерфейсу користувача) і kernel32.dll (функції, реалізовані у ВС і ядрі). Після того як застосування звернеться до функції Win32 API, спочатку буде викликана відповідна функція з бібліотеки підсистеми Win32. Розглянемо варіанти виконання такого виклику. 1. Якщо функції потрібні тільки ресурси її бібліотеки, виклик повністю виконується в адресному просторі застосування без переходу в режим ядра. 2. Якщо потрібен перехід у режим ядра, з коду бібліотеки підсистеми виконується системний виклик. Так відбувається у більшості випадків, наприклад під час створення вікон або елементів керування. 3. Функція бібліотеки підсистеми може звернутися до процесу підсистеми Win32, при цьому: · коли потрібна тільки функціональність, реалізована даним процесом, переходу в режим ядра не відбувається; · коли потрібна функціональність режиму ядра, процес підсистеми Win32 виконує системний виклик аналогічно до варіанта 2. Зазначимо, що до виходу Windows NT 4.0 (1996 рік) віконна і графічна підсистеми працювали в режимі користувача як частина процесу підсистеми Win32 (тобто виклики базових графічних функцій Win32 API оброблялися відповідно до варіанта 3). Надалі для підвищення продуктивності реалізацію цих підсистем було перенесено в режим ядра [14]. Підсистема POSIX працює в режимі користувача й реалізує набір функцій, визначених стандартом POSIX 1003.1. Оскільки застосування, або прикладні програми (applications), написані для однієї підсистеми, не можуть використати функції інших, у POSIX-програмах не можна користуватися засобами Win32 API (зокрема, графічними та мережними функціями), що знижує важливість цієї підсистеми. Підсистема POSIX не є обов'язковим компонентом Windows XP.
Застосування користувача Застосування користувача можуть бути створені для різних підсистем середовища. Такі застосування використовують тільки функції відповідного API. Виклики цих функцій перетворюються в системні виклики за допомогою динамічних бібліотек підсистем середовища.
Структура заголовка об'єкта Об'єкти складаються з двох частин: заголовка і тіла об'єкта. У заголовку міститься інформація, загальна для всіх об'єктів, у тілі - специфічна для об'єктів конкретного типу. До атрибутів заголовка об'єкта належать: · ім'я об'єкта і його місце у просторі імен; · дескриптор захисту (визначає права, необхідні для використання об'єкта); · витрата квоти (ціна відкриття дескриптора об'єкта, дає змогу регулювати кількість об'єктів, які дозволено створювати); · список процесів, що дістали доступ до дескрипторів об'єкта. Менеджер об'єктів здійснює керування об'єктами на підставі інформації з їхніх заголовків.
Об'єкти типу формат і вміст тіла об'єкта визначається його типом. Новий тип об'єктів може бути визначений будь-яким компонентом ВС. Існує визначений набір типів об'єктів, які створюються під час завантаження системи (такі об'єкти, наприклад, відповідають процесам, відкритим файлам, пристроям введення-виведення). Частина характеристик об'єктів є загальними для всіх об'єктів цього типу. Для зберігання відомостей про такі характеристики використовують спеціальні об'єкти типу (type objects). У такому об'єкті, зокрема, зберігають: · ім'я типу об'єкта («процес», «потік», «відкритий файл» тощо); · режими доступу (залежать від типу об'єкта: наприклад, для файла такими режимами можуть бути «читання» і «запис»). Об'єкти типу недоступні в режимі користувача. Методи об'єктів Коли компонент ВС створює новий тип об'єкта, він може зареєструвати у диспетчері об'єктів один або кілька методів. Після цього диспетчер об'єктів викликає ці методи на певних етапах життєвого циклу об'єкта. Наведемо деякі з методів об'єктів: · open - викликається при відкритті дескриптора об'єкта;
|
|||||||
Последнее изменение этой страницы: 2016-07-11; просмотров: 642; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.144.15.205 (0.017 с.) |