
- •Ю.Б. Гриценко
- •Учебное пособие
- •ТОМСК — 2009
- •Ю.Б. Гриценко
- •Учебное пособие
- •Гриценко Ю.Б.
- •ВВЕДЕНИЕ
- •1 ВВЕДЕНИЕ В ОПЕРАЦИОННЫЕ СРЕДЫ, СИСТЕМЫ И ОБОЛОЧКИ
- •1.1 Основные понятия
- •1.2 Классификация операционных систем
- •1.3 Классификация построений ядер операционных систем
- •1.4 Представление об интерфейсах прикладного программирования
- •1.4.1 Общие задачи и функции интерфейсов прикладного программирования
- •1.4.2 Варианты реализации интерфейсов прикладного программирования
- •1.4.3 Характеристики интерфейсов прикладного программирования на различных уровнях реализаций
- •1.4.4 Платформенно-независимый интерфейс POSIX
- •1.5 Основные принципы построения операционных систем
- •Вопросы для самопроверки
- •2 ОБЗОР ПОПУЛЯРНЫХ ОПЕРАЦИОННЫХ СИСТЕМ
- •2.1 Операционные системы фирмы Microsoft
- •2.1.2 Операционная система Windows 2000
- •2.1.3 Операционная система Windows XP
- •2.1.4 Операционная система Windows 2003 Server
- •2.1.5 Операционная система Windows Vista
- •2.1.6 Операционная система Windows 2008 Server
- •2.2 Операционные системы семейства Unix
- •2.2.1 История разработки систем UNIX
- •2.2.2 Примеры различных версий Unix
- •2.2.3 Программное обеспечение X Window
- •2.3 Операционная система OS/2
- •2.3.1 История разработки системы OS/2
- •2.3.2 Особенности архитектуры и интерфейса OS/2 Warp
- •2.3.3 Серверная операционная система OS/2 Warp 4.5
- •2.3.4 Эпоха eComStation
- •2.4 Операционные системы реального времени. Операционная система QNX
- •2.4.1 Общее представление об операционных системах реального времени
- •2.4.2 Особенности архитектура системы QNX
- •2.4.3 Основные механизмы QNX
- •Вопросы для самопроверки
- •3 ИНТЕРФЕЙСЫ ОПЕРАЦИОННЫХ СИСТЕМ
- •3.1 Интерфейс командной строки ОС Windows
- •3.2 Интерфейс командной строки ОС Unix
- •Вопросы для самопроверки
- •ГЛОССАРИЙ
- •СПИСОК ЛИТЕРАТУРЫ
- •КОНТРОЛЬНЫЕ РАБОТЫ
- •Контрольная работа № 1
- •Контрольная работа № 2
31
Как правило, API не стандартизированы. В каждом конкретном случае набор вызовов API определяется, прежде всего, архитектурой ОС и ее назначением. В то же время принимаются попытки стандартизировать некоторый базовый набор функций, поскольку это существенно облегчает перенос приложений из одной ОС в другую. Таким примером может служить известный и, пожалуй, самый распространенный стандарт — стандарт POSIX (см. пункт 1.4.4). В этом стандарте перечислен большой набор функций, их параметров и возвращаемых значений. Стандартизированными, согласно POSIX, являются не только обращения к API, но и файловая система, организация доступа к внешним устройствам, набор системных команд (команд управления процессами). Использование в приложениях этого стандарта позволяет в дальнейшем легко переносить такие программы из одной ОС в другую путем простейшей перекомпиляции исходного текста.
Частным случаем попытки стандартизации API является внутренний корпоративный стандарт компании Microsoft, известный как WinAPI. Он включает в себя следующие реализа-
ции: Win16, Win32s, Win32, WinCE. С точки зрения WinAPI,
который в силу ряда идеологических причин является обязательным графическим «оконным» интерфейсом пользователя, базовой задачей выступает окно. Таким образом, WinAPI изначально ориентирован на работу в графической среде. Однако базовые понятия дополнены традиционными функциями, в том числе частично поддерживается стандарт POSIX.
1.4.4 Платформенно-независимый интерфейс POSIX
Платформенно-независимый системный интерфейс для компьютерного окружения POSIX (Portable Operating System Interface for Computer Environments) — это стандарт IEEE (Institute of Electrical and Electronics Engineers — институт инженеров по электротехнике и радиоэлектронике), описывающий системные интерфейсы для открытых ОС, в том числе оболочки, утилиты и инструментарии
(http://standards.ieee.org/regauth/posix/index.html).

32
Помимо этого, согласно POSIX, стандартизированными являются задачи обеспечения безопасности, задачи реального времени, процессы администрирования, сетевые функции и обработка транзакций. Стандарт базируется на UNIX-системах, но допускает реализацию и в других ОС. POSIX возник как попытка всемирно известной организации IEEE пропагандировать переносимость приложений в UNIX-средах путем разработки абстрактного, платформенно-независимого стандарта. Однако POSIX не ограничивается только UNIX-системами; существуют различные реализации этого стандарта в системах, которые соответствуют требованиям, предъявляемым стандартом IEEE Standard 1003.1-1990 (POSIX.1). Например, известная ОС реального времени QNX соответствует спецификациям этого стандарта, что облегчает перенос приложений в эту систему, но UNIXсистемой не является ни в каком виде, ибо ее архитектура использует абсолютно иные принципы.
Этот стандарт подробно описывает систему виртуальной памяти VMS (Virtual Memory System), многозадачность МРЕ
(MultiProcess Executing) и технологию переноса операционных систем CTOS (An Operating System produced Convergent Technology …). Таким образом, на самом деле POSIX представляет собой множество стандартов, именуемых POSIX.I — POSIX.12. В табл. 1.1 приведены основные направления, описываемые данными стандартами. Следует также особо отметить, что в POSIX. 1 предполагается язык С в качестве основного языка описания системных функций API.
Таблица 1.1 — Семейство стандартов POSIX
Стандарт |
Стан- |
Краткое описание |
дарт |
||
|
ISO |
|
POSIX.0 |
Нет |
Введение в стандарт открытых систем. Данный |
|
|
документ не является стандартом в чистом виде, |
|
|
а представляет собой рекомендации и краткий |
|
Да |
обзор технологий |
POSIX.1 |
Системный API (язык С) |
|
POSIX.2 |
Нет |
Оболочки и утилиты, одобренные IEEE |

|
|
33 |
Окончание табл. 1.1 |
|
|
|
Стан- |
|
Стандарт |
дарт |
Краткое описание |
|
ISO |
|
POSIX.3 |
Нет |
Тестирование и верификация |
POSIX.4 |
Нет |
Задачи реального времени и нити |
POSIX.5 |
Да |
Использование языка ADA применительно к |
|
Нет |
стандарту POSIX.1 |
POSIX.6 |
Системная безопасность |
|
POSIX.7 |
Нет |
Администрирование системы |
POSIX.8 |
Нет |
Сети |
|
|
«Прозрачный» доступ к файлам |
|
|
Абстрактные сетевые интерфейсы, не зависящие |
|
|
от физических протоколов вызова удаленных |
|
|
процедур RPC (Remote Procedure Calls) |
|
|
Связь системы с протоколо-зависимыми прило- |
|
Да |
жениями |
POSIX.9 |
Использование языка FORTRAN применительно |
|
|
Нет |
к стандарту POSIX.1 |
POSIX.10 |
Super-computing Application Environment Profile |
|
|
|
(AEP) — профиль для суперкомпьютерных ок- |
|
Нет |
ружений |
POSIX.11 |
Обработка транзакций АЕР |
|
POSIX.12 |
Нет |
Графический интерфейс пользователя GUI |
Таким образом, программы, написанные с соблюдением данных стандартов, будут одинаково выполняться на всех POSIX-совместимых системах. Однако стандарт в некоторых случаях носит лишь рекомендательный характер. Часть стандартов описана очень строго, тогда как другая часть только поверхностно раскрывает основные требования.
Нередко программные системы заявляют как POSIX-сов- местимые, хотя таковыми их назвать нельзя. Причины кроются в формальности подхода к реализации POSIX-интерфейса в различных ОС. К сожалению, достаточно часто с целью увеличения производительности той или иной подсистемы либо из соображений введения фирменных технологий, которые ограничивают использование приложения соответствующей операционной