Різні системні виклики

Існує, крім описаних вище, ще безліч системних викликів. Зараз ми розгля-немо тільки чотири з них. Виклик chdir змінює поточний робочий каталог. Після виклику chdir ("/ usr / ast / test"):

процедура відкриття файлу xyz відкриє / usr / ast / test / xyz. Використання поняття

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

користувачів. Системний виклик chmod надає можливість зміни режимного коду файлу. Наприклад, наступний виклик надасть всім, крім власника, доступ до файлу тільки для читання; власник ж зможе ще й виконувати файл:

chmodC'file ". 0644);

Системний виклик kill дозволяє користувачам і призначеним для користувача

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

обробити сигнал, тоді прибуття сигналу знищує процес (звідси пішла назва виклику, kill в перекладі означає «вбивати, знищувати»). Стандартом POSIX визначено декілька процедур, які мають відношення до часу. Наприклад, time повертає поточний час у секундах, причому нулем вважається опівночі 1 січня 1970 (мається на увазі початок дня, а не його кінець). На комп'ютерах з 32-розрядними словами максимальна величина, яку може повернути time, становить 232-1 с (використовується позитивне ціле число). Ця величина відповідає періоду трохи більше 136 років. Таким чином, в 2106 32-розрядні системи UNIX «зійдуть з розуму», імітуючи знамениту проблему 2000 року (Y2K). Якщо зараз у вас 32-розрядна система UNIX, ми рекомендуємо вам поміняти її на 64-розрядну, перш ніж настане 2106.

Windows Win32 API

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

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

Звичайно, в Windows теж є системні виклики. У UNIX виклики майже один

до одного ідентичні бібліотечним процедурам (згадаймо read), використовуваним

для звернення до системних викликів. Іншими словами, для кожного системного

виклику існує одна бібліотечна процедура, звичайно з тією ж назвою, яка викли-кається для звернення до нього. Це було показано на рис. 1.17. Крім того, в стандарті POSIX всього лише близько 100 процедурних дзвінків. Ситуація в системі Windows зовсім інша. По-перше, фактичні системні виклики запус-каються для їх виконання бібліотечні виклики повністю розділені. Корпорацією Microsoft визначений набір процедур, званий Win32 API (Application Program Interface - інтерфейс прикладних програм). Передбачається, що програмісти повинні використовувати його для виклику служб операційної системи. Цей інтерфейс частково підтримується всіма версіями Windows, починаючи з Windows 95. Відокремлюючи інтерфейс від фактичних системних викликів, Microsoft підтримує можливість зміни з часом дійсних системних викликів (навіть від однієї версії до іншої), не роблячи при цьому недійсними існуючі програми. Ситуація насправді складається неоднозначна, тому що в Windows 2000 з'явилося багато нових викликів, раніше недоступних. У цьому розділі Win32 означає інтерфейс, підтримуваний всіма версіями Windows.Кількість викликів в Win32 API украй велика, виклики обчислюються тисячами. Крім того, хоча багато з них є системними, істотне число працює цілком у просторі користувача. Через це в Windows неможливості неможливо зрозуміти, чи є виклик системним (тобто виконуваних ядром), або просто бібліотечним викликом, який обробляється в просторі користувача. В принципі виклик, який вважається системним в одній версії Windows, може виконуватися в просторі користувача в інших версіях, і навпаки. При обговоренні системних викликів Windows в цій книзі ми будемо використовувати відповідні процедури Win32, оскільки Microsoft гарантує, що вони не мінятимуться. Але варто завжди пам'ятати, що не всі вони є справжніми

системними викликами (тобто перериваннями з перемиканням в режим ядра).

Інша відмінність полягає в тому, що в UNIX графічний інтерфейс користувача (наприклад, X Windows або Motif) запускається цілком у просторі користувача. Тому для виводу на екран досить системного виклику wri te і кілька інших незначних викликів. Звичайно, існує досить велика кількість звернень до X Windows і GUI, але вони не є системними викликами в будь-якому сенсі цього слова.

На противагу цьому Win32 API має величезну кількість викликів для управління вікнами, геометричними фігурами, текстом, шрифтами, смугами прокрутки, діалоговими вікнами, пунктами меню та іншими елементами

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

в режимі ядра (це вірно для більшості версій Windows, але не для всіх), виклики є системними, інакше виклики є тільки бібліотечними. Чи повинні ми обгово-рювати ці виклики в книзі чи ні? Так як вони насправді не пов'язані з функціями операційної системи, ми вирішили цього не робити, незважаючи на те, що вони виконуються ядром. Читачам, які цікавляться Win32 API, ми рекомендуємо звернутися до будь-якої з безлічі книг по цьому предмету, наприклад [146, 271 або 302].

Навіть перерахування всіх викликів Win32 API виходить за рамки цієї книги,

тому ми обмежимося тими з них, які приблизно відповідають функціональності викликів UNIX, перерахованих в табл. 1.1. Ці виклики показані в табл. 1.2.

Таблиця 1.2. Виклики Win32 API, приблизно відповідні викликам UNIX,

перелічених у табл. 1.1

Тепер коротко пройдемося по списку, представленому в табл. 1.2. Виклик CreateProcess створює новий процес. Він комбінує роботу викликів fork і execve в UNIX. У цього виклику є безліч параметрів, що визначають властивості створених процесів. У Windows немає такої ієрархії процесів, як в UNIX, тому тут

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

Наступні шість викликів оперують файлами і функціонально схожі на свої аналоги в UNIX, незважаючи на те що вони мають різні параметри і деталі. Таким чином, файли можна відкривати, закривати і читати практично так само, як в UNIX. Виклики SetFiiePointer і GetFiieAttributesEx встановлюють позицію покажчика та отримують деякі з атрибутів файлу. У Windows також є каталоги, їх створюють і видаляють виклики CreateDi rectory і RemoveDi rectory відповідно. Тут теж є поняття поточного каталогу, він задається за допомогою SetCurrentDi rectory. Для отримання поточного часу використовується GetLocaiTime.

В інтерфейсі Win32 не існує пов'язаних файлів, монтування файлових систем, захисту файлів і сигналів, тому також немає і викликів, відповідних викликам UNIX. Звичайно, в Win32 є величезна кількість найрізноманітніших інших викликів, яких не має UNIX, особливо що відносяться до управління графічним інтерфейсом. Однак система Windows 2000 має ретельно продуману систему безпеки і, крім того, підтримує зв'язки між файлами. Варто зробити ще одне, останнє зауваження щодо Win32. Win32 НЕ є повністю однаковим і послідовним інтерфейсом. Причиною цього стала необхідність забезпечення сумісності з раніше використовувалися в Windows 3.x 16-розрядним інтерфейсом.

Структура операційної системи

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

Тобто ми знайомі з програмним інтерфейсом), саме час заглянути всередину.

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

Монолітні системи

У загальному випадку організація монолітної системи являє собою «великий

безлад ». Тобто структура як така відсутня. Операційна система написана у вігляді набору процедур, шкірно з якіх Може віклікаті Інші, коли їй Це потрібно. При вікорістанні Такої ТЕХНІКИ Кожна процедура системи має строго Певний інтерфейс у термінах параметрів и результатів, и Кожна має можлівість віклікаті будь-яку іншу для виконання деякої необхідної для неї роботи. Для побудова монолітної системи Необхідно скомпілюваті ВСІ окремі процедури, а потім зв'язати їх у єдиний об'єктній файл за допомога компонувальніка. Тут, по суті, повністю відсутня пріховування деталей реалізації - шкірно процедура бачіть будь-яку іншу процедуру (на відміну від структури, містіть модулі, В якій велика Частина ІНФОРМАЦІЇ є локальною для модуля та процедури модуля можна віклікаті Тільки через спеціально певні точки входу).

Однак навіть Такі монолітні системи можут мати деяки структуру. При зверненні до системних вікліків, підтрімуваніх операційною системою,

Параметри поміщаються в строго певні місця - регістрі або стек, після

Чого віконується Спеціальна команда переривані, відома Як виклик ядра або виклик супервізора. Ця команда перемікає машину з режиму Користувача в режим ядра и передає УПРАВЛІННЯ операційній сістемі, Що видно на кроці б рис. 1.17. Потім Операційна система перевіряє Параметри виклик, щоб

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

виклик в ЯКОСТІ індексу. У ku елементі табліці містіться посилання на процедуру ОБРОБКИ системного виклик k (крок 7 на рис. 1.17). Така організація

операційної системи передбачає наступна структуру:

1. Головна програма, Яка віклікає необхідну службово процедуру.

2. Набір службово процедур, Що виконують сістемні Виклики.

3. Набір утіліт, Що обслуговують службові процедури.

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

Рис. 1.21. Проста модель монолітної системи