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

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

КУРСОВА РОБОТА

Рівень операційної системи

Вступ

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

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

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

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

1. Загальні особливості операційної системи

1.1 Класифікація та функції операційної системи

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

У залежності від функціонального призначення, ОС можна класифікувати за різними критеріями:

1) однозадачні та багатозадачні операційні системи;

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

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

2) однокористувацькі та багатокористувацькі;

3) з підтримкою роботи в мережі (мережеві ОС) та без підтримки роботи в мережі.

4) операційна система для виконання функцій сервера мережі або робочої станції (клієнта мережі).

Настільні (DeskTop) - найбільш поширений клас операційних систем призначений для виконання досить широкого класу задач, від домашнього використання до робочої станції мережі (сімейство операційних систем Windows 9x - для платформи Intel, Mac OS - для платформи Macintosh). Універсальність ОС досягається шляхом прийняття розробниками певних компромісів у побудові ядра, алгоритмах роботи з пам'яттю, надійності, захищеності, продуктивності.

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

Найбільш популярними мережевими операційними системами є Windows NT та версії UNIX систем, зокрема все більшого застосування набуває вільно поширювана ОС Linux.

1.2 Складові ОС, їх призначення, завантаження ОС

Складові компоненти ОС такі: ядро, драйвери пристроїв, оболонка, системні утиліти.

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

Рис. 1.1 Приклад виконання кількох задач (gtop)

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

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

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

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

2. Основні компоненти операційної системи

2.1 Віртуальна пам'ять

операційний віртуальний пам'ять програма

У перших комп'ютерах пам'ять була дуже мала за обсягом і до того ж дорого коштувала. IBM-650, провідний комп'ютер того часу (кінець 50-х років), містив всього 2000 слів пам'яті. Один з перших 60 компіляторів ALGOL був написаний для комп'ютера з об'ємом пам'яті всього 1024 слова. Стародавня система з поділом часу прекрасно працювала на комп'ютері PDP-1, загальний обсяг пам'яті якого складав всього 4096 18-розрядних слів для операційної системи і користувацьких програм. У ті часи програмісти витрачали дуже багато часу, намагаючись вмістити свої програми в крихітну пам'ять. Часто доводилося використовувати більш повільний алгоритм тільки тому, що більш швидкий не вдавалося розмістити в пам'яті комп'ютера.

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

Хоча ця технологія широко використовувалася протягом багатьох років, вона вимагала тривалої кропіткої роботи, пов'язаної з керуванням оверлеями. У 1961 році група дослідників з Манчестера (Англія) запропонувала метод автоматичного виконання процесу накладання, при якому програміст міг взагалі не знати про цей процес. Цей метод, в основі якого, як зараз кажуть, лежить використання віртуальної пам'яті, мав очевидну перевагу, оскільки звільняв програміста від маси нудної роботи.

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

2.2 Віртуальні команди вводу-виводу

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

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

2.3 Збереження інформації у зовнішній пам'яті. Файлова система.

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

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

- збереження досить великих обсягів даних.

- збережену в зовнішній пам'яті інформацію перед використанням завантажують в оперативну пам'ять комп'ютера.

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

1) підвести зчитуючий / записуючий елемент до вказаного місця (сектора);

2) прочитати дані з вказаного місця (сектора);

3) записати дані у вказане місце (сектор).

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

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

Доріжка - сектори, що належать одній поверхні і знаходяться на однаковій відстані від осі обертання.



Рис. 2.1 Організація дискового накопичувача

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

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

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

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

- інформацію про те, який саме відкритий файл потрібно зчитувати;

- покажчик на буфер в пам'яті, в який потрібно помістити дані;

- число зчитувальних байтів.

Даний системний виклик поміщає потрібні дані в буфер. Зазвичай він повертає число лічених байтів. Це число може бути менше запропонованого числа (наприклад, не можна зчитати 2000 байт з файлу розміром 1000 байт).

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

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

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

2.4 Команди керування каталогами

Багато років тому програми і дані зберігалися на перфокартах. Оскільки розмір програм збільшувався, а даних ставало все більше, така форма зберігання стала незручною. Тоді виникла ідея замість перфокарт використовувати для зберігання програм і даних допоміжну пам'ять (наприклад, диск). Інформація, доступна для комп'ютера без втручання людини, називається оперативною (on-line). Навпаки, автономна (off-line) інформація вимагає втручання людини (наприклад, щоб вставити компакт-диск).

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

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

У цьому випадку підтримуються системні виклики, принаймні, для наступних функцій:

– створення файлу та включення його в каталог;

– видалення файлу з каталогу;

– перейменування файлу;

– зміна статусу захисту файлу.

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

2.5 Віртуальні програми для паралельної роботи

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

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

Альтернативний спосіб підвищення швидкодії комп'ютера - створення машини з декількома процесорами. Комп'ютер, що містить 1000 процесорів з часом циклу 1 нс на кожен, буде мати такі ж можливості, як процессор з часом циклу 0,001 нс, але перший реалізувати набагато простіше і дешевше.

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

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

2.6 Формування процесу

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

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

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

3. Операційні системи Unix та Windows

3.1 UNIX

Операційна система UNIX була розроблена в компанії Bell Labs на початку 70-х років. Перша версія була написана Кеном Томпсоном на асемблері для міні-комп'ютера PDP-7. Потім з'явилася друга версія для комп'ютера PDP-11, вже на мові С. Її автором був Денніс Рітчі. У 1974 році Рітчі і Томпсон опублікували дуже важливу роботу про систему UNIX. За цю роботу вони були нагороджені престижною премією Тьюрінга Асоціації обчислювальної техніки. Після публікації багато університетів попросили у Bell Labs копію UNIX. Оскільки материнська компанія Bell Labs, AT & T, була в той момент регульованою монополією і їй не дозволялося брати участь в комп'ютерному бізнесі, університети змогли купити операційну систему UNIX за невелику плату.

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

Одним з перших університетів, які купили UNIX, був Каліфорнійський університет в Берклі. Оскільки в наявності були всі вихідні коди, в Берклі зуміли істотно перетворити UNIX. Серед змін було перенесення цієї системи на мінікомп'ютер VAX, створення віртуальної пам'яті зі сторінковою організацією, розширення імен файлів з 14 до 255 символів, а також підтримка мережевого протоколу TCP / IP, який зараз широко використовується в Інтернеті (багато в чому завдяки тому факту, що він був задіяний в системі Berkeley UNIX).

Поки в Берклі йшла вся ця робота, компанія AT & T самостійно продовжували удосконалювати UNIX, в результаті в 1982 році з'явилася операційна система System III, а в 1984 - System V. У кінці 80-х років широко використовували дві різні і абсолютно несумісні версії UNIX: Berkeley UNIX і System V. Такий стан речей разом з відсутністю стандартів на формати програм в двійковому коді значно перешкоджало комерційному успіху UNIX. Постачальники програмного забезпечення не могли писати програми для UNIX, оскільки не було ніякої гарантії, що ці програми зможуть працювати на будь-якій версії UNIX (в цьому відношенні у MS-DOS була значна перевага). Після довгих суперечок організація по стандартам при інституті IEEE (Institute of Electrical and Electronic Engineers - інститут інженерів з електротехніки та електроніки) випустила стандарт POSIX (Portable Operating System Interface - інтерфейс переносних операційних систем), відомий також як стандарт IEEE Р1003. Пізніше цей стандарт став міжнародним.

Стандарт POSIX складається з декількох частин, кожна з яких присвячена окремій області UNIX. Перша частина, Р 1003.1, визначає системні виклики; друга частина, Р1003.2, - основні прикладні програми і т.д. Стандарт Р 1003.1 визначає близько 60 системних викликів, які повинні підтримуватись всіма системами. Це виклики для читання і запису файлів, створення нових процесів і т.д. Зараз практично всі системи UNIX підтримують системні виклики, перераховані в Р1003.1, проте багато систем підтримують і додаткові системні виклики, зокрема ті, що були реалізовані в System V і в Berkeley UNIX. Зазвичай до набору POSIX додаються до 200 системних викликів.

У 1987 році автор цієї книги випустив вихідний код для однієї з версій UNIX, названої MINUX і призначеної для установки в університетських комп'ютерних системах. Одним із студентів, які познайомилися з MINUX в університеті Хельсінкі і встановили цю систему на домашньому компьютері, виявився Лінус Торвальдс. Вивчивши MINIX в деталях, Лінус вирішив написати власну версію операційної системи, яка отримала ім'я Linux і стала з часом дуже популярною. MINIX і Linux схожі, і тому майже всі відомості про MINIX, актуальні і відносяться до Linux. За внутрішньою структурою разноманітні версії UNIX істотно розрізняються, але ці відмінності в даному випадку несуттєві. (рис. 3.1).

У UltraSPARC III використовується операційна система Solaris, і хоча основою для неї є версія System V, вона також підтримує багато викликів Berkeley UNIX.

Рис. 3.1. Пінгвін Tux - логотип і талісман ядра юнікс

Системні виклики керування файлами і каталогами - це найважливіша і об'ємна категорія. Більшість з них відносяться до стандарту Р 1003.1, інші беруть початок в System V. Сфера використання мереж в більшій мірі відноситься до Berkeley UNIX, а не до System V. Саме в Берклі було введено поняття сокета як кінцевої точки мережевого з'єднання. Моделлю для цієї концепції стали 4-провідні настінні розетки для телефонів. Процес в системі UNIX може створити сокет, підключитися до нього і встановити з'єднання з сокетом на віддаленому комп'ютері. Через це з'єднання можна потім пересилати дані в обох напрямках, зазвичай по протоколу TCP / IP. Оскільки мережеві технології в системі UNIX застосовувалися десятиліттями, значне число серверів в Інтернеті використовують саме UNIX.

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

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

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

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

Пізніше, коли з'явилися графічні термінали, в Массачусетському техно-логічному інституті для UNIX була розроблена віконна система, що отримала назву X Windows. Ще пізніше поверх X Windows був встановлений повно-функціональний графічний користувальницький інтерфейс (Graphical User Interface, GUI), названий Motif. Оскільки ядро повинно було залишатися компактним, практично весь код для X Windows і Motif працює поза ядром в користувацькому режимі.

3.2 Windows ХР

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

У 1995 році з'явилася система Windows 95, але вона не знаменувала собою відмову від MS-DOS, просто на зміну колишньої версії MS-DOS прийшла нова - MS-DOS 7.0. Windows 95 і MS-DOS 7.0 в сукупності мали характерні особливості розвиненої операційної системи, в тому числі підтримували віртуальну пам'ять, керування процесами і мультипрограмування. Однак операційна система Windows 95 не була повністю 32-розрядною програмою. Вона містила великі фрагменти старого 16-розрядного коду (з невеликими вкрапленями 32-розрядного) і як і раніше використовувала файлову систему MS-DOS з усіма її недоліками. Єдиними змінами у файловій системі стали збільшення довжини імен файлів (раніше в MS-DOS довжина імен файлів не повинна була перевищувати 8 + 3 символів) і зняття колишнього обмеження (рівного 65 536) на кількість дискових блоків.

Навіть в системі Windows 98, що вийшла в 1998 році, 16-розрядний код MS-DOS (на цей раз версії 7.1) все ще присутній. Система Windows 98 не надто відрізнялася від Windows 95, хоча частина функцій перекочували від MS-DOS до Windows, а дисковий формат, відповідний для дисків більшого розміру, став стандартним. Основною відмінністю був користувальницький інтерфейс, який об'єднав робочий стіл, Інтернет і телебачення, зробивши систему більш автономною. Саме це і привернуло увагу міністерства юстиції США, яке звинуватило Microsoft в порушенні антимонопольного законодавства. Через деякий час в світ вийшла кілька вдосконалена редакція Windows 98 під ім'ям Windows Millenium Edition (ME), але проіснувала вона недовго.

Під час усіх цих подій компанія Microsoft розробляла зовсім нову 32-розрядну операційну систему. Ця нова система називалася Windows New Technology (нова технологія Windows), або скорочено Windows NT. Спочатку передбачалося, що вона замінить всі операційні системи, призначені для комп'ютерів на базі процесорів Intel. Однак її поширення йшло дуже повільно і пізніше була переорієнтована на більш дорогі комп'ютери. Друга версія Windows NT, названа Windows 2000, мала набагато більший успіх, в тому числі і в сегменті домашніх комп'ютерів. Послідовницею Windows 2000 стала система Windows ХР, яка представляла собою не що інше, як злегка вдосконалений варіант Windows 2000 року (рис. 3.2).

ОС Windows ХР продається в двох версіях: для серверів і для клієнтів. Ці дві версії практично ідентичні і побудовані на базі одного вихідного коду. Перша версія призначена для файлових серверів і серверів друку локальних мереж і має більш складні функції керування, ніж клієнтська версія, яка орієнтована на застосування та одного користувача. Є особливий варіант серверної версії, призначений для керування великими корпоративними мережами. Різні версії настроюються по-різному, і кожна з них оптимізована для очікуваного оточення. У всьому іншому ці версії схожі. Практично всі виконувані файли всіх версій ідентичні. Система для Windows ХР сама ідентифікує свою версію за спеціальною переміною у внутрішній структурі даних (системному реєстрі). Користувачам заборонено змінювати цю змінну і, таким чином, перетворювати дешеву клієнтську версію в більш дорогу серверну або корпоративну.

.

Рис. 3.2 Логотип Windows

MS-DOS і всі попередні версії Windows були розраховані на одного користувача. ОС Windows ХР підтримує мультипрограмування, тому на одній і тій же машині в один і той же час можуть працювати кілька користувачів.

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

ОС Windows ХР являє собою реальну 32-розрядну операційну систему з мультипрограмування. Вона підтримує кілька користувацьких процесів, кожен з яких отримує в своє розпорядження повний 32-розрядний віртуальний адресний простір з підкачкою сторінок. Крім того, сама система написана в 32-розрядних кодах.

ОС Windows ХР на відміну від Windows 95 має модульну структуру. Вона складається з невеликого ядра, яке працює в привілейованому режимі, і декількох серверних процесів, що працюють в режимі користувача. Користувацькі процеси взаємодіють з серверними процесами відповідно до моделі клієнт-сервер: клієнт посилає запит серверу, а сервер виконує необхідну роботу і відправляє результат клієнтові. Модульна структура дозволяє переносити ОС Windows ХР на деякі комп'ютери, які не відносяться до Intel (DEC Alpha, IBM Power PC і SGI MIPS). Однак з міркувань продуктивності, починаючи з Windows NT 4.0, більша частина системних функцій була перенесена назад в ядро.

Можна дуже довго розповідати про структуру і інтерфейс Windows ХР, але оскільки в різних операційних системах нас в першу чергу цікавлять віртуальні машини, про структуру системи ми розповімо дуже коротко, а потім перейдемо до інтерфейсу системних викликів.

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

У самому низу розташований рівень апаратних абстракцій. Він повинен надавати операційній системі деякі абстрактні пристрої, позбавлені всіх вад і недоліків реальних пристроїв. До модельованих пристроїв відноситься кеш-пам'ять, розташована поза мікросхемами, тактові генератори, шини вводу-виводу, контролери переривань, контролери прямого доступу до пам'яті. Якщо ці пристрої надати операційній системі в ідеалізованому вигляді, це спростить перенесення Windows ХР на інші апаратні платформи, оскільки більшу частину змін буде потрібно зробити лише в одному місці.

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

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

Рис. 3.3. Функції ядра

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

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

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

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

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

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

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

Монітор безпеки включає механізм безпеки Windows ХР, який відповідає вимогам Помаранчевої книги міністерства оборони США. У Помаранчевій книзі перераховується величезна кількість правил, якими повинна задовольняти система, починаючи з пароля і закінчуючи обнуленням віртуальних сторінок перед їх повторним використанням.

Інтерфейс графічних пристроїв керує виводом зображень на монітор і принтер. Він надає системні виклики, які дозволяють користувацьким програмам записувати інформацію на монітор або принтер незалежно від типів цих пристроїв. Він також надає драйвери пристроїв для виведення графіки. У перших версіях Windows ХР інтерфейс графічних пристроїв був реалізований в користувацькому просторі, проте продуктивність в цьому випадку залишала бажати кращого, тому програмісти компанії Microsoft перенесли його в ядро. Багатьма системними викликами керує також модуль Win32. Спочатку він теж розташовувався в користувацькому просторі, але пізніше з метою підвищення продуктивності був переміщений в ядро.

Верхній рівень виконуючою системи - системні служби. Вони надають інтерфейс виконуючій системі. Системні служби отримують системні виклики Windows ХР і для їх виконання викликають інші частини виконуючої системи.

Поза ядром знаходяться користувальницькі програми і підсистема оточення. Потреба в підсистемі оточення пояснюється тим, що користувацькі програми не орієнтовані на самостійне виконання системних викликів (хоча технічно така можливість у них є). Тому підсистемне оточення експортує певну групу викликів функцій, з якими користувацькі програми можуть працювати. Спочатку існували три підсистеми оточення: Win32 (для програм Windows NT, Windows 2000, Windows ХР і Windows 95/98/ME), POSIX (для переносних програм UNIX) і OS / 2 (для переносних програм OS / 2). З них на даний момент підтримується тільки підсистема Win32. У той же час існує ряд нових служб модуля UNIX, що в деякій мірі забезпечують підтримку цієї операційної системи.

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

Перейдемо до обговорення послуг, які надаються операційною системою Windows ХР. Її інтерфейс - це основний засіб зв'язку програміста з системою. На жаль, компанія Microsoft не опублікувала повний список системних викликів Windows ХР, і, крім того, вона міняє їх від випуску до випуску. За таких обставин практично неможливе написання програм, які безпосередньо здійснюють системні виклики.

Зате компанія Microsoft визначила набір функцій, відомий всім як Win32 API (Application Programming Interface - прикладний програмний інтерфейс). Це бібліотечні функції, які виконують певні дії або в системі шляхом системних викликів, або в деяких випадках безпосередньо в бібліотечній процедурі користувацького простору або підсистемі Win32. Набір Win32 API при створенні нових версій Windows ХР не змінюється. Однак крім Win32 API існують процедури Windows ХР API, які в нових версіях Windows ХР можуть мінятися. Так як виклики Win32 API задокументовані і досить стабільні, ми зосередимо нашу увагу саме на них, а не на системних викликах Windows ХР. Коли в Windows була введена підтримка 64-розрядних машин, компанія Microsoft змінила назву набору з Win32 на Win64, однак для наших цілей вивчення 32-розрядної версії цілком достатньо.

У системах Win32 API і UNIX застосовуються зовсім різні підходи. В UNIX всі системні виклики загальновідомі і формують мінімальний інтерфейс: видалення хоча б одного з них змінить функціонування операційної системи. Підсистема Win32 надає надлишковий інтерфейс. Тут часто одну і ту ж дію можна виконати трьома або чотирма різними способами. Крім того, Win32 включає в себе багато функцій, які не представляються системним викликами (наприклад, копіювання цілого файлу).

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

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

Win32 API є і в системі Windows 95/98 (а також в операційній системі Windows СЕ, призначеної для установки в різного роду електронних пристроях), щоправда, з деякими винятками. Наприклад, Windows 95/98 не має захисту, тому ті виклики, які пов'язані із захистом, просто повертають код помилки. Крім того, для імен файлів в Windows ХР використовується набір символів Unicode, який не підтримується в Windows 95/98. Існують відмінності в параметрах деяких викликів API. У Windows ХР, наприклад, всі екранні координати є 32-розрядними числами, а в Windows 95/98 використовуються тільки молодші 16 біт (для сумісності з Windows 3.1). Підтримання набору функцій Win32 API на різних операційних системах спрощує перенесення програм між ними, але при цьому дещо в реальній системі викликів залишається недоступним.

3.3 Віртуальна пам'ять UNIX

Модель пам'яті Unix досить проста. Кожен процес має три сегменти: код, дані і стек. У машині з лінійним адресним простором код зазвичай розташовується в нижній частині пам'яті, а за ним йдуть дані. Стек поміщається у верхній частині пам'яті. Розмір коду фіксований, а дані та стек можуть збільшуватися або зменшуватися. Таку модель легко реалізувати практично на будь-якій машині.

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

Опис системи UNIX (віртуальна пам'ять з підкачкою сторінок на вимогу) в цілому відповідає версії Berkeley UNIX, однак версії Sysytem V і Solaris мають деякі особливості, що дозволяють користувачам керувати віртуальною пам'яттю. Найважливішою є здатність процесу відображати файл або частину файлу на частину адресного простору процесу. Наприклад, якщо файл розміром 12 Кбайт відображається на віртуальну адресу 144К, то в комірці з адресою 144К буде знаходитися перше слово цього файлу. Таким чином, можна виконувати ввід-вивід файлу без системних викликів. Оскільки розмір деяких файлів перевищує розмір віртуального адресного простору, можна відображати не весь файл, а тільки його частину. Для відображення спочатку потрібно відкрити файл і отримати дескриптор файлу fd (file descriptor). Дескриптор використовується для ідентифікації відображуваного файлу. Потім процес здійснює виклик

paddr = mmap (virtual_address, length, protection, flags, fd, file_offset)

Цей виклик відображає length байт, починаючи зі зсуву file_offset у файлі, на віртуальний адресний простір, починаючи з адреси virtual_address. Параметр flags вимагає, щоб система вибрала віртуальну адресу, яка потім повертається в параметрі paddr. Видима область повинна бути вирівняна в межах сторінки і містити ціле число сторінок. Параметр protection взначає рівень захисту, включаючи можливість читання, запису і виконання (в будь-якій комбінації). Відображення можна надалі видалити за допомогою команди unmap.

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

3.4 Віртуальна пам'ять Windows XP

У Windows ХР кожен користувацький процес має власний віртуальний адресний простір. Довжина віртуальної адреси становить 32 біта, тому у кожного процесу є 4 Гбайт віртуального адресного простору. Нижні 2 Гбайт призначені для коду та даних процесу; верхні 2 Гбайт забезпечують доступ (обмежений) до пам'яті ядра. Виняток становлять серверні версії Windows ХР, в яких поділ пам'яті може бути іншим (3 Гбайт користувачеві і 1 Гбайт ядру). Віртуальний адресний простір з підкачкою сторінок на вимогу містить сторінки фіксованого розміру (4 Кбайт на машині Pentium 4).

Кожна віртуальна сторінка може знаходитися в одному з трьох станів: вільна (free), зарезервована (reserved) або виділена (committed). Вільна сторінка в поточний момент не використовується, і звернення до неї викликає помилку відсутності сторінки. Коли процес починається, всі його сторінки знаходяться у вільному стані до тих пір, поки програма і початкові дані не будуть відображені на свій адресний простір. Якщо код або дані відображені в сторінку, то така сторінка є виділеною. Звернення до виділеної сторінки буде успішним, якщо сторінка знаходиться в основній пам'яті. Якщо сторінка відсутня в основній пам'яті, відбудеться помилка, і операційній системі доведеться викликати потрібну сторінку з диску. Віртуальна сторінка може знаходитися і в зарезервованому стані. Це означає, що сторінка залишається недоступною для відображення до тих пір, поки резервування не буде скасовано. Крім атрибутів стану, сторінки мають і інші атрибути (наприклад, вказують на можливість читання, запису і виконання). Верхні 64 Кбайт і нижні 64 Кбайт пам'яті завжди вільні, щоб можна було відшукувати помилки покажчиків (неініціалізовані покажчики часто рівні 0 або -1).

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

Windows ХР, як і System V, дозволяє відображати файли прямо на області віртуального адресного простору. Якщо файл відображений на адресний простір, його можна зчитувати або записувати шляхом звичайних звернень до пам'яті.

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

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

3.5 Оболонка користувача. Інтерфейс командного рядка. Графічний інтерфейс користувача

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

Інтерфейс - засоби та сукупність команд операційної системи для здійснення діяльності користувачами щодо опрацювання інформації засобами обчислювальної системи.

Алгоритм роботи інтерфейсного модуля досить простий:

1) більшу частину часу він очікує введення команди користувача;

...