Операционные системы

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

Реферат

На тему: ОПЕРАЦИОННЫЕ СИСТЕМЫ

Подготовила: Ахметзянова З.

АСФ 2 курс

Глава 1. Операционная система Windows 3.x

1.1 История и архитектура

операционная система windows

Операционная система Windows 1.x (1987 г.) разрабатывалась фирмой Microsoft по заказу IBM прежде всего для того, чтобы подготовить пользователей к графическому интерфейсу, который должен был появиться в новой версии совместно разрабатываемой этими двумя фирмами OS/2. Но значительный успех на рынке, пришедший с версией Windows 3.0, явился одной из причин того, что фирма Microsoft решила разорвать свое сотрудничество с IBM и сосредоточиться на этой линии продуктов.

Строго говоря, Windows 1.x - 3.x представляет собой не самостоятельную ОС, а надстройку над MS DOS [2]. Windows запускается как приложение MS DOS, которое перехватывает у MS DOS управление некоторыми ресурсами - прежде всего памятью, процессами и символьными устройствами. Управление же файловой системой остается за MS DOS и для выполнения соответствующих функций Windows обращается к MS DOS.

Архитектура Windows 3.x показана на рисунке 2.1. Ядро Windows состоит из трех модулей, из которых: Kernel - обеспечивает системные функции, User - объекты интерфейса пользователя, GDI - графические функции.

Windows первоначально разрабатывалась для процессора Intel 80286, а затем - и для Intel 80386, поэтому ядро и драйверы Windows работают в защищенном режиме. Драйверы устройств Windows уже не используют функции BIOS, а самостоятельно управляют внешними устройствами на физическом уровне. (Это не относится к дисковым драйверам, так как функции файловой системы остаются за MS DOS).



Рисунок 1 Архитектура Windows 3.x

1.2 Управление процессами

Windows 3.x обеспечивает невытесняющую многозадачность. В среде Windows могут выполняться одновременно несколько программ-процессов, но активный процесс не может быть прерван системой, переключение процессов может происходить только в том случае, если текущий активный процесс переходит в состояние ожидания. Отсюда программирование в Windows является событийно-управляемым. Программа представляет собой цикл, каждая итерация которого начинается с ожидания какого-либо сообщения (каковым может быть, например, нажатие кнопки мыши), затем сообщение обрабатывается, и следует новая итерация цикла, которая начинается с ожидания нового сообщения. Ожидание сообщения в начале каждого цикла и является тем моментом, когда процесс может быть вытеснен. Если же программа находится в бесконечном цикле, в теле которого нет системных вызовов, включающих в себя ожидание, то она не может быть прервана и блокирует работу всей системы.

1.3 Управление памятью

Как было сказано, Windows первоначально разрабатывалась для процессора Intel 80286, в котором механизм динамической трансляции адресов работает в сегментной модели виртуальной памяти и используется 16-разрядное адресное слово. Поэтому адресное пространство процесса состоит из сегментов размером не более 64 Кбайт каждый, хотя общее виртуальное адресное пространство процесса может достигать 4 Гбайт. API управления памятью позволяет выделять/освобождать сегменты, а также управлять перемещаемостью и вытесняемостью сегментов. При адаптации к процессору Intel 80386 (сегментно-страничная модель и 32-разрядное адресное слово) версии Windows для этого процессора стали использовать страничную часть механизма трансляции адресов для создания общего для всех процессов виртуального страничного пространства, размер которого в 4 раза превышает размер реальной памяти, а в этом страничном пространстве память распределяется сегментами. API продолжает оставаться сегментным, а свопинг ведется на страничном уровне. Имеется две группы вызовов API - для управления локальными и глобальными сегментами.

В Windows используется динамическая компоновка программ во время загрузки. Модули динамической компоновки, в том числе и системные, совместно используются выполняющимися программами.

1.4 Другие свойства Windows 3.x

Хотя приоритет в создании полноэкранного графического интерфейса пользователя принадлежит фирме Apple (она даже пыталась в судебном порядке оспорить правомочность использования этой идеи фирмой Microsoft), именно в Windows с таким интерфейсом познакомилась основная масса пользователей. Каждый процесс в Windows выполняется в собственном окне, имеющем типовые элементы управления. Для представления объектов используется иконика, многие операции над объектами выполняются при помощи мыши. Однако, интерфейс Windows 3.x не является объектно-ориентированным, так как не обеспечивает автоматического связывания с каждым объектом определенного набора свойств и методов. Средства графического интерфейса неотъемлемо встроены в ядро системы.

Средства взаимодействия процессов - общие сегменты памяти и сообщения. Сообщения посылаются от одного процесса другому или порождаются внешними событиями. В системе имеется общая очередь сообщений, обслуживаемая только по дисциплине FIFO, что снижает надежность системы, так как если процесс не выбирает адресованное ему сообщение, оно блокирует всю очередь.

Поскольку Windows 3.x использует защищенный режим процессора, она обеспечивает значительно лучшую защиту ресурсов, чем MS DOS. Вместе с тем, Windows 3.x является однопользовательской системой, т.е., не включает в себя средств аутентификации пользователей и, соответственно, авторизации. Последняя версия - Windows for Workgroups 3.11 - расширена средствами совместного использования ресурсов локальной сети (файлы, принтеры) группами пользователей.

Windows 3.x, по-видимому, можно считать бесперспективной системой, так как объем парка ПЭВМ той мощности, для которой применение Windows 3.x может быть оптимальным, неуклонно уменьшается. Применяются компьютеры либо с совсем малым объемом ресурсов (MS DOS), либо с большим их объемом (Windows 9x). Для Windows 3.x было создано большое число приложений, и поэтому среда Windows 3.x поддерживается в более поздних ОС (Windows 9x/NT/2000, OS/2). Но в настоящее время процесс вытеснения этих приложений новыми версиями, разработанными для современных ОС, уже почти завершен.

Глава 2. Операционные системы Windows 9x/ME

2.1 История и архитектура

ОС Windows 95 разработана фирмой Microsoft прежде всего для предотвращения перехода пользователей Windows 3.x в среду OS/2 с увеличением мощности персональных вычислительных средств. Windows 95 справилась с этой задачей, но не за счет своих объективных достоинств, а за счет крупномасштабной рекламной компании, начавшейся задолго до ее появления на рынке.

В отличие от Windows 3.x, Windows 95 является полнофункциональной ОС, осуществляющей управление всеми ресурсами вычислительной системы [5]. Для ее выполнения не требуется MS DOS, код MS DOS v.7 встроен в Windows 95 только для поддержки выполнения приложений MS DOS.

Архитектура Windows 95 показана на рисунке 3.1. ОС Windows 98 [15] (и Windows ME) отличаются от Windows 95 прежде всего дизайном интерфейса и некоторыми системными сервисами, но строятся на принципиально том же ядре.

Рисунок 3.1 Архитектура Windows 95

Windows 95 разработана для процессора не ниже Intel 80386, то есть ориентирована на 32-разрядное машинное слово и защищенный режим процессора. Основу той части Windows 95, которая работает в незащищенном режиме, составляет так называемая системная виртуальная машина, которая обеспечивает среду выполнения всех приложений, написанных для Windows 95. Функции модулей GDI, Kernel, User - те же, что и в Windows 3.x, около 50% объема этих модулей просто перенесены из Windows 3.x.

В среде системной виртуальной машины также работает виртуальная машина Windows. Эта виртуальная машина полностью эмулирует Windows 3.x с ее 16-разрядной адресацией, режимом невытесняющей многозадачности, общей очередью и т.д., и приложения Windows 3.x работают в ее среде.

Для выполнения приложений MS DOS создается виртуальная машина MS DOS как копия эталонной машины MS DOS. Каждая такая виртуальная машина MS DOS обеспечивает адресное пространство для выполнения программ MS DOS и содержит код MS DOS v.7. Выполнение низкоуровневых операций обеспечивается для виртуальной машины MS DOS частью ОС Windows 95, работающей в режиме ядра (уровень 0). Приложения MS DOS независимы друг от друга, но они совместно используют драйверы реального режима и разделяют младшие адреса памяти.

Часть системы, работающая в режиме ядра, обеспечивает собственно управление ресурсами: памятью, процессами и т.д.

2.2 Управление процессами

Windows 95 обеспечивает вытесняющую многозадачность, то есть разделение процессорного времени между двумя и более процессами и нитями. Однако, поскольку часть кода ядра ОС заимствована из Windows 3.x и является нереентерабельной, прерывания активного процесса возможны не в любой момент времени. Для совместимости с заимствованным нереентерабельным кодом в Windows 95 введены специальные модули-переходники, которые, во-первых, преобразуют 32-разрядный API в 16-разрядный, а, во-вторых, блокирует совместное использование нереентерабельной части ядра.

Планирование процессов выполняется с динамическим перевычислением приоритетов. Механизм управления процессами обеспечивается двумя модулями:

основной диспетчер, который перевычисляет приоритеты через каждые 20 мсек (этот интервал называется квантом);

диспетчер квантования, который распределяет время внутри кванта.

Квант отдается процессу с наивысшим на данный момент приоритетом. Если несколько процессов имеют высший приоритет, то квант делится между ними поровну.

Всего имеется 32 градации приоритетов. Правила изменения приоритетов следующие:

внешнее событие (нажатие клавиши или кнопки мыши) повышает приоритет;

повышенный таким образом приоритет постепенно снижается до исходного (если не наступает новое событие);

приоритет процесса, который захватывает монопольный ресурс (например, дисковый ввод-вывод) повышается, это повышение отменяется, когда ресурс освобождается.

2.3 Управление памятью

Адресное пространство процесса (речь идет о процессах-приложениях, разработанных для Windows 95) структурировано таким образом, как показано на рисунке 3.2.



Рисунок 3.2 Структура адресного пространства для приложения Win32

область адресного пространства 0 - 16 Кбайт не адресуется; эта область используется драйверами реального режима MS DOS;

область 16 Кбайт - 4 Мбайт не используется процессом (она используется компонентами реального режима);

область 4 Мбайт - 2 Гбайт составляет частное адресное пространство процесса, в ней размещаются локальные коды и данные процесса;

область 2 Гбайт - 3 Гбайт - совместно используемые объекты: библиотеки динамической компоновки, в том числе и системные, относящиеся к кольцу 3, такие, как Kernel, GDI и USER; все объекты, совместно используемые разными процессами, причем такой объект имеет один и тот же виртуальный адрес во всех его использующих процессов; в этом адресном пространстве также выполняются приложения Win16;

в области 3 Гбайт - 4 Гбайт размещаются компоненты системы, работающие в реальном режиме, в том числе VxD, подсистемы управления виртуальными машинами и файлами.

Каждому процессу в Windows 95 выделяется всего один сегмент и виртуальный адрес, таким образом, представляет собой только смещение в сегменте. Для процесса, таким образом, обеспечивается плоская модель памяти. Элементы страничных каталогов, относящиеся к адресному пространству выше 2 Гбайт, для всех процессов указывают на одни и те же таблицы страниц второго уровня. Обращение процесса к системе имеет вид вызова процедуры, находящейся в адресном пространстве процесса (в старших адресах памяти). Совместное использование верхней половины виртуального адресного пространства всеми процессами создает потенциальную (и часто реализующуюся в Windows 9x) возможность нарушений в работе системы: если один процесс "портит" содержимое верхней части своего адресного пространства, то он тем самым "портит" его и для всех других процессов.

Совместно используемые области памяти, размещаемые в адресном пространстве 2 - 3 Гбайт, называются в Windows 9x "файлами, отображаемыми в память". Один процесс создает такой файл, другой - открывает его. Системные вызовы создания/открытия "файла, отображаемого в память" возвращают виртуальный адрес общей области памяти (одинаковый для всех процессов, его использующих).

2.4 Файловая система

В Windows 95 применяется механизм инсталлируемой (загружаемой) файловой системы, который обеспечивает системы работать с томами, содержащими различную организацию данных. Структура инсталлируемой файловой системы показана на рисунке 3.3.



Рисунок 3.3 Инсталлируемая файловая система Windows 9x

Самый верхний уровень файловой системы Диспетчер Инсталлируемой Файловой Системы (ISF - Installable File System), который обеспечивает интерфейс между запросами процессов и конкретной файловой системой. Диспетчер IFS играет роль абстрактной файловой системы. Конкретные файловые системы называются драйверами файловых систем (FSD - File System Driver). Драйверы FSD ответственны за семантику конкретных файловых систем. Каждый такой FSD поддерживает определенную организацию файловые системы и обслуживает запросы, которые передает ему Диспетчер IFS. Диспетчер IFS обеспечивает также для FSD некоторые общие сервисные функции: управление памятью, управление событиями, синтаксический разбор имен файлов и т.п. Каждый FSD при своей инициализации регистрируется у Диспетчера IFS, выдавая специальный системный вызов монтирования (для тома) или регистрации (для сетевой файловой системы). В процессе регистрации FSD передает Диспетчеру IFS адреса своих входных точек. Эти входные точки однозначно соответствуют файловым системным вызовам из состава API. Таким образом, в самой ОС почти совсем отсутствует общая обработка системных вызовов, и основная функция IFS - опознание того FSD, которому следует переадресовать вызов. Опознание адресата Диспетчер IFS производит следующим образом:

если одним из параметров вызова является полное имя файла, Диспетчер IFS использует идентификатор диска для определения соответствующего FSD по таблице томов;

если одним из параметров вызова является манипулятор открытого файла, Диспетчер IFS использует манипулятор для определения соответствующего FSD по таблице открытых файлов;

если происходит запрос, с которым Диспетчер IFS не может разобраться, он поочередно вызывает все зарегистрированные FSD, пока один из них не примет запрос.

Подсистема ввода-вывода - IOS - выполняет две функции: управляющего модуля, который распределяет обращения, и сервисные функции для драйверов.

Драйвер отслеживания тома - VTD - контролирует смену носителей на устройствах.

Cпецифический дисковый драйвер - TSD - управляет всеми устройствами определенного типа и преобразует виртуальные адреса на устройстве в физические.

Драйверы независимых разработчиков - VSD - (необязательные) выполняют любую дополнительную обработку данных.

Драйвер порта - аппаратно-зависимый драйвер, выполняющий обмен данных с устройством на низком уровне.

В Windows 95 идея независимой от драйверов модификации данных реализована таким образом, что в ОС определено общее количество звеньев в цепочке обработки, которую проходят данные, - 32. IOS составляет уровень 0, драйвер порта - уровень 31. Между ними, следовательно, возможно еще 30 уровней, которые могут быть заняты драйверами VSD, при установке драйвера VSD можно выбрать уровень, на котором он будет включен в цепочку.

Что касается конкретной файловой системы, то файловые системы Windows 95 - VFAT (виртуальная FAT) и FAT-32. Их структура в принципе такая же, как и FAT-16, но VFAT позволяет работать с длинными именами файлов (за счет того, что одному файлу может соответствовать несколько элементов каталога: основной и продолжения), а в FAT-32 вдобавок к этому элемент FAT имеет размер 32 бита, следовательно, позволяет работать с большим числом кластеров на диске. Структура элемента каталога - та же, что и у FAT-16, но размер имени файла может достигать 250 символов. Это достигается тем, что для файлов с длинными именами выделяется несколько элементов каталога, и специальная комбинация атрибутов файла отличает элемент, содержащий продолжение имени от первого элемента. Кроме того, корневой каталог в FAT-32 уже не привязан жестко к определенному месту на диске, следовательно, снимается ограничение на его размер.

2.5 Другие свойства Windows 9x

Средства взаимодействия процессов в Windows 95 - семафоры, события и переменные взаимного исключения. Каждое из этих средств имеет собственный API для создания и управления, но для ожидания на всех объектах синхронизации используются одни и те же системные вызовы.

Интерфейс Windows 95 хорошо известен всем пользователям, так что нет нужды описывать его подробно. Он создавался по образцу объектно-ориентированного интерфейса Mac OS фирмы Apple. Однако, интерфейс Windows 95 является не объектно-, а документо-ориентированным. Объектами в строгом смысле являются файлы программ и данных. Некоторые управляющие компоненты (в том числе и сам Рабочий Стол) объектами не являются, а только имитируют объектное поведение. В Windows 98 в связи с интеграцией в нее Web-броузера внешний вид интерфейса несколько изменился, но принципы его построения и функционирования остались те же.

Поскольку Windows 95 является однопользовательской системой, задача защиты ресурсов ставится в ней только в смысле разделения ресурсов разных процессов. Принятые в системе "облегченные" методы такого разделения создают потенциальную возможность для возникновения ошибок в системе, для устранения которых потребовалась бы тщательная отладка системного кода. Любому пользователю Windows 95, однако, хорошо известно, что такая отладка фирмой Microsoft не производится. Но эту ситуацию можно если не простить, то понять. Windows 95 является персональной ОС и не предназначена для выполнения критических приложений. Как правило, сбой системы не приводит к потерям большим, чем несколько минут, потраченных на перезагрузку, и испорченное настроение. Пока пользователи продолжают покупать ОС, пусть даже и ненадежно работающую, для фирмы нет смысла увеличивать затраты на повышение надежности.

С самого начала фирма Microsoft рассматривала Windows 95 как некий суррогат, призванный обеспечить удержание фирмой позиций до выхода в свет новой ОС (сначала предполагалось, что это будет Windows NT v.4, затем - Windows 2000). Ориентация на широкий круг непрофессиональных пользователей и активная, хотя и не всегда честная рыночная политика привели к тому, что Windows 95 стала монополистом на рынке персональных ОС. Версия Windows 98 строится на том же ядре и отличается прежде всего интегрированным в систему Web-броузером Microsoft Internet Explorer. В 2000 году появилась новая версия - Windows ME (Millenium Edition). Следует ожидать, что эта версия будет не только использоваться, но и развиваться в течение еще нескольких лет прежде, чем уступит место более надежным системам (например, Windows 2000).

Глава 3. Операционная система OS/2

3.1 История и архитектура

Первая версия OS/2 появилась в 1987 г. и являлась совместной разработкой фирм IBM и Microsoft. В ходе работы над следующими версиями фирма Microsoft, во-первых, сочла завышенными требования IBM к надежности, во-вторых, решила делать ставку на свой продукт Windows и прекратила свое участие в проекте.

Первая версия OS/2 предназначалась для компьютеров на базе процессора Intel 80286 с его 16-разрядным словом и сегментной моделью виртуальной памяти. В последующих версиях и релизах поэтапно вводились: новая файловая система, графический интерфейс, сегментно-страничная модель памяти, 32-разрядность. Однако, все релизы первой и второй версий OS/2 [6] предъявляли требования к ресурсам, превышающие средний уровень имеющихся в то время ПЭВМ, поэтому эти версии были несколько "тяжеловесны". Этот недостаток был устранен в версии 3 - OS/2 Warp (1995 г.), в которой все свойства ОС были оптимизированы в компактном ядре. Эта версия стала выходить как клиентской, так и в серверной редакции (в последнюю был включен продукт IBM LAN Server).

При значительном сходстве с архитектурой Windows 9x архитектура OS/2 Warp обладает рядом существенных отличий от нее.

Системная виртуальная машина OS/2 обеспечивает выполнение приложений OS/2 - 16- и 32-разрядных. Отдельная виртуальная машина создается для эмуляции среды Windows 3.x, в этой среде 16-разрядные приложения Windows выполняются в общем адресном пространстве, в режиме невытесняющей многозадачности - как и в Windows 9x. Однако, можно запускать приложения Windows и в отдельных адресных пространствах, тогда они выполняются в режиме вытесняющей многозадачности вместе с другими приложениями Windows, OS/2 и MS DOS. Приложения MS DOS выполняются каждое в среде собственной виртуальной машины MS DOS. Отдельной частью ядра OS/2 является ядро VDM (виртуальной машины MS DOS), которое обеспечивает эмуляцию функций MS DOS (в отличие от Windows 9x здесь нет кода ОС MS DOS), эмуляцию процессора Intel 8086 и диспетчеризацию виртуальных машин MS DOS.

Архитектура OS/2 Warp [20] показана на рисунке 3.1.

Рисунок 3.1 Архитектура OS/2 Warp

Графическая оболочка Workplace Shell является отдельным приложением, запускаемым опционно, OS/2 может функционировать и без графической оболочки, в режиме командной строки.

3.2 Многозадачность

С самого начала OS/2 являлась многозадачной системой с вытесняющей многозадачностью. Многозадачность в этой системе имеет три уровня: сеанс, процесс, нить.

Сеанс - это окно на экране. Сеанс может быть запущен в полноэкранном или оконном режиме. Каждый сеанс имеет собственную виртуальную консоль, включающую в себя логические эквиваленты монитора, клавиатуры и мыши; командный прцессор (CMD.COM в сеансах OS/2 или COMMAND.COM в сеансах MS DOS); начальный командный файл (OS2ININ.CMD в сеансах OS/2 или AUTOEXEC.BAT в сеансах MS DOS). Сеанс предоставляет пользователю самостоятельную рабочую среду (MS DOS, Windows 3.x или OS/2). Когда сеанс выдвигается на передний план, соответствующая сеансу виртуальная консоль становится эквивалентной физической консоли. API OS/2 позволяет порождать новые сеансы и управлять из родительского сеанса состоянием сеанса дочернего.

В каждом сеансе может быть запущен один или (только в сеансе OS/2) несколько процессов. В соответствии с общепринятым подходом процессу в OS/2 соответствует программа с набором выделенных ей ресурсов. В API системы имеются системные вызовы для порождения нового процесса с выполнением в нем другой программы или для смены программы, выполняемой в текущем процессе. Порождаемые процессы связаны с породившим отношениями "потомок-предок". Наследование ресурсов (файлов, каналов) может устанавливаться для каждого экземпляра ресурса избирательно.

Каждый процесс состоит из одной или нескольких нитей. Нить является объектом планирования процессорного времени. Нити разделяют большую часть ресурсов процесса, в составе которого они выполняются, но каждая нить имеет собственный контекст и собственный стек.

С самого начала OS/2 проектировалась как система с вытесняющей многозадачностью. Участки нереентерабельного кода в ядре системы минимизированы, а MS DOS и Windows также эмулируются ядром, поэтому OS/2 в состоянии обеспечить более оперативное переключение процессов, чем Windows 95. OS/2 управляет процессами в режиме квантования времени, размер кванта является параметром, задаваемым при загрузке системы. При освобождении процессора или по истечении кванта активным назначается процесс с наивысшим приоритетом. В системе имеются следующие 4 класса приоритетов процессов (в порядке убывания приоритетности):

критический - для процессов реального времени и сетевых коммуникаций; для процессов этого класса гарантируется время реакции не более 6 мксек;

серверный - для процессов, выполняющих запросы от других процессов (введен в 4-й версии OS/2);

нормальный - для интерактивных процессов;

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

Внутри каждого класса приоритет процесса перевычисляется динамически (имеется еще по 32 градации приоритета в каждом классе) по таким правилам:

процесс, окно которого является в данный момент активным, получает "добавку переднего плана";

процесс, выполняющий операцию ввода-вывода, получает "добавку ввода-вывода", которая делает его приоритет наивысшим в классе; по окончании операции ввода-вывода эта добавка отбирается у процесса;

процесс, пребывающий в состоянии ожидания дольше некоторого времени (задаваемого при загрузке), получает "добавку голодания", которая ставит его сразу после критического класса и позволяет практически немедленно получить квант процессорного времени, после использования кванта эта добавка отбирается у процесса.

3.3 Управление памятью

Ранние версии OS/2 были ориентированы на сегментную модель виртуальной памяти. OS/2 Warp обеспечивает для процесса плоскую модель памяти, хотя поддерживает также и API старой, сегментной модели. Структура виртуального адресного пространства процесса OS/2 показана на рисунке 3.2.

Рисунок 3.2 Адресное пространство процесса OS/2

Качественно структура адресного пространства процесса - такая же, как и в Windows 95. В последних релизах OS/2 Warp Server for e-business граница частного адресного пространства процесса может быть поднята до 3 Гбайт. Плоская модель памяти обеспечивается теми же средствами, что и в Windows 95: единственный сегмент для процесса и использование каталога страниц. Однако, в OS/2 на одни и те же таблицы страниц второго уровня указывают только элементы страничных каталогов, относящихся к адресному пространству выше 3 Гбайт. Поэтому объекты, совместно используемые несколькими процессами, имеют разные виртуальные адреса для разных процессов.

Динамическая компоновка во время загрузки является важным компонентом системы, и большинство системных модулей оформлены в виде библиотек динамической компоновки - DLL. Имеется также возможность компоновки во время выполнения - в этом случае требуемый модуль DLL должен быть явным образом загружен программой и определены адреса его входных точек, для чего имеется соответствующий API.

3.4 Устройства и файловая система

Драйверы устройств имеют "классическую" двухуровневую структуру и устанавливаются при загрузке системы. Драйверы выполняются на уровне защиты 2 процессора Imtel/Pemtium, что дает им возможность выполнять команды ввода-вывода, но не другие привилегированные команды. Выполнение низкоуровневых системных функций (например, управление реальной памятью) обеспечивается для драйверов системным сервисом - внутренним вызовом DosHepl.

Подобно Windows 95, OS/2 обеспечивает инсталлируруемые файловые системы. Только файловая система FAT-16 поддерживается ядром ОС. Сетевая файловая система и CDFS поддерживаются через механизм инсталлируемой файловой системы. Основная же инсталлируемая файловая система OS/2 - HPFS.

HPFS - Hight Performance File System (высокопроизводительная файловая система) - разработана совместно фирмами IBM и Microsoft в период их совместной работы над OS/2 версии 1.2. HPFS была призвана прежде всего заменить FAT MS DOS и отличается от последней высокой эффективностью в управлении жесткими дисками большого объема и поддержкой длинных (до 255 символов имен файлов). Структура тома в HPFS показана на рисунке 13.10.а. Начальная часть диска (16 блоков) резервируется под блок загрузки и загрузочную информацию, суперблок, запасной блок (копию суперблока) и т.д. Корневой каталог HPFS расположен в логической середине диска, чтобы минимизировать перемещение головок. Эти системные структуры используются для загрузки ОС, поддержки работы файловой системы и восстановления. Распределяемое дисковое пространство разбивается на, так называемые, полосы размером по 8 Мбайт каждая. Каждой полосе соответствует битовая карта размером 2 Кбайт. Один элемент битовой карты соответствует одному 512-байтному блоку (сектору) полосы и отражает его состояние (занят/свободен). Битовые карты поочередно размещаются в начале и в конце каждой полосы, таким образом, две смежные полосы образуют непрерывный участок дискового пространства размером около 16 Мбайт. Файловая система планирует размещение новых файлов на диске по возможности в непрерывном участке дискового пространства. Кроме того, за концом нового файла оставляется свободный участок "на вырост", что дает файлу возможность в будущем расширяться, не теряя непрерывности в размещении.

а). структура тома HPFS

б). элемент каталога HPFS

Рисунок 3.3 Файловая система HPFS

Организация файлов и каталогов в HPFS включает в себя две структуры, показанные на рисунке 4.3.б: элемент каталога (DIRBLK) и дескриптор файла или каталога (Fnode). В суперблоке содержится указатель на дескриптор корневого каталога. Каталог состоит из элементов каталога, которые организованы в сбалансированное двоичное дерево, упорядоченное для поиска по имени файла/каталога. В элементе каталога содержится указатель на дескриптор файла/каталога. Основное содержание дескриптора - план размещения файла. Как отмечалось выше, файловая система стремится разместить весь файл в одном экстенте, но не гарантирует такого размещения. Файлы, характеризующиеся значительной изменчивостью, могут занимать большое число экстентов. Элемент плана размещения состоит из начального адреса экстента и его длины. Описания 8 экстентов могут быть размещены непосредственно в дескрипторе. Если же файл состоит из большего числа экстентов, план его размещения структурируется в B-дерево с корневым узлом в дескрипторе.

Для повышения производительности HPFS использует кеширование данных при записи на диск и отложенную запись

Новая версия этой файловой системы - HPFS386 оптимизирована для работы с новыми поколениями процессоров Intel/Pentium и большими дисковыми системами. Она отличается тем, что значительная часть драйвера файловой системы работает на уровне защиты 0. В ней значительно увеличены размеры кешей, сняты некоторые ограничения, повышена надежность (поддерживается технология RAID-1). HPFS386 интегрируется с IBM LAN Server и обеспечивает хранение списков контроля доступа в файловой системе.

3.5 Средства взаимодействия

OS/2 обладает полным набором средств взаимодействия процессов, описанным нами в главе 9 части 1.

В системе имеется 9 типов сигналов (в том числе 3 - пользовательских) с возможностью устанавливать их собственную обработку или игнорировать сигнал (кроме сигнала KILL).

Общие области памяти выделяются как сегменты и могут быть именованными или неименованными.

Неименованные каналы создаются специальным системным вызовом (одним вызовом создается один канал - для чтения или для записи), дальнейшая работа с каналом происходит с использованием API файлов. Для именованных каналов наряду с файловым API имеются специальные операции, обеспечивающие обмен данными в одном вызове (открытие канала, запись, чтение, закрытие).

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

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

Все именованные средства взаимодействия вписываются в пространство имен файловой системы, и имена их выгладят как имена файлов, расположенных в специальных каталогах.

3.6 Другие свойства OS/2

Хотя OS/2 в настоящее время позиционируется на рынке как серверная ОС, ее ядро продолжает оставаться однопользовательским, то есть, на уровне ядра OS/2 пользователей не различает. Защита в ядре относится прежде всего к защите ресурсов процессов, которая обеспечивается надежной изоляцией адресных пространств процессов друг от друга. Контроль доступа обеспечивается промежуточным программным обеспечением (IBM LAN Server и др.), поставляемым "в одной коробке" с OS/2.

Графический интерфейс OS/2 во многом напоминает интерфейс Windows 95. Это объясняется тем, что разработчики обеих систем брали за образец интерфейс MacOS. Однако IBM разрабатывала интерфейс OS/2 в непосредственном сотрудничестве с фирмой Apple, поэтому он не только внешне подобен образцу, но и полностью воплощает его объектно-ориентированные свойства. Workplace Shell (рабочий стол) и Warp Center (панель быстрого доступа, подобная линейке программ в Windows 9x) являются приложениями, запускаемыми по выбору.

OS/2 может также работать и в режиме командной строки. Набор команд OS/2 является расширением набора команд MS DOS. Наиболее интересной из этого расширения нам представляется команда CALL, которая позволяет запустить программу без ожидания ее завершения. Именно команда CALL создает возможность запускать несколько процессов в одном сеансе OS/2. OS/2 имеет богатейшие возможности для командных файлов, которые обеспечиваются языком REXX, являющимся неотъемлемой частью ОС. Команды и программы, выполняемые в интерпретаторе REXX, имеют возможность обмениваться сигналами и данными, используя перенаправление ввода-вывода или интерфейс очередей.

В первые два года своего существования OS/2 Warp, а затем и ее версия 4 - Merlin - конкурировала на рынке персональных ОС с Windows 95. Так, OS/2 Merlin стала первой ОС со встроенной поддержкой мультимедиа, голосового ввода и Java-платформой. Несмотря на то, что по объективным показателям OS/2, по крайней мере, не уступала своему конкуренту, она потерпела поражение, предже всего - из-за отсутствия должной рекламы. В 1998 г. фирма IBM решила, что рынок персональных систем не входит в сферу ее стратегических интересов, и позиционировала OS/2 как серверную систему. В таком качестве OS/2 приобрела значительное число корпоративных пользователей, особенно в Европе. Версия 5 OS/2 - Aurora, расширенная прежде всего поддержкой SMP-архитектуры и файловой системой JFS, заимствованной из ОС AIX (см. главу 7), появилась в 1999 г. Долгое время она существовала только в серверном варианте, и только в 2001 г. появилась клиентская редакция этой версии. Хотя OS/2 продолжает эксплуатироваться и развиваться, в настоящее время фирма IBM исключила из своих стратегических интересов любые ОС для платформы Intel/Pentium (а возможно - и саму эту платформу) и не занимается продвижением OS/2 на рынке. Поскольку стратегия разработки приложений IBM в последнее время диктует ориентацию на платформенную независимость, IBM предлагает использовать OS/2 прежде всего как платформу для разработчиков Java-приложений с последующим переносом результатов на другие платформы. Предложение вполне разумное, так как OS/2 является, во-первых, чрезвычайно устойчивой, а во-вторых, виртуальная машина Java от IBM для OS/2 является одной из самых эффективных (если не самой эффективной) из всех существующих.

Вместе с тем, в движении Открытых Кодов существует стойкое и активное ядро сторонников OS/2, не желающих отказываться от нее даже как от настольной системы. Среди акций этого движения можно назвать давно и успешно развивающийся проект по обеспечению выполнения среде OS/2 приложений Win32, а также недавно начавшееся движение за перевод OS/2 в открытые коды. Можно предполагать, что эта OS/2 не прекратит своего существования даже, если IBM от нее совсем откажется.

Глава 4. Операционные системы Windows NT/2000

4.1 История и архитектура

Windows NT явилась продолжением фирмой Microsoft проекта OS/2, предпринятым фирмой Microsoft после того, как разошлись ее пути с IBM. В качестве руководителя проекта Windows NT был приглашен Д.Катлер, имеющий большой опыт в разработке операционных систем в фирме DEС (ОС VAX VMS).

С самого начала Windows NT планировалась как ОС, предназначенная для выполнения функций сервера. Windows NT является полностью 32-разрядной ОС с объектно-ориентированной структурой и строится на базе микроядра. Последнее обстоятельство позволило сделать ОС доступной на большом числе аппаратных платформ CISC- и RISC-процессоров, в том числе, и в симметричных многопроцессорных архитектурах. Однако, начиная с версии 4, Windows NT работает только на процессорной архитектуре Intel/Pentium. Архитектура ОС [10, 35] представлена на рисунке 4.1.

Рисунок 4.1 Архитектура Windows NT/2000

Реализация концепции микроядра в Windows NT состоит в том, что ОС состоит из процессов-серверов, выполняющих непосредственное обслуживание пользовательских процессов в пользовательском режиме, и части системы, работающей в режиме ядра, выполняющей по запросам процессов-серверов низкоуровневые и критические операции.

Строго говоря, Windows NT не является по-настоящему системой с микроядром, так как, по определению, в таких системах только компактное микроядро работает в привилегированном режиме. Здесь же помимо того, что разработчики называют "микроядром" ("ядро" на рис.5.1), в таком режиме работает и огромная испольнительная подсистема.

Часть системы, работающая в режиме ядра, состоит из нескольких слоев.

Уровень аппаратных абстракций виртуализирует аппаратные интерфейсы. При его создании ставилась цель подготовки процедур, которые позволяли бы единственному драйверу конкретного устройства поддерживать функционирование этого устройства на всех аппаратных платформах. Аппаратные абстракции скрывают от вышележащих частей ОС такие детали как интерфейс ввода-вывода, контроллеры прерываний и другие аппаратно-зависимые и специфические функции. Уровень аппаратных абстракций также обеспечивает программные механизмы управления и обмена данными между процессорами в симметричных многопроцессорных архитектурах. Ядро и драйверы устройств для выполнения аппаратно зависимых функций обращаются к уровню аппаратных абстракций, хотя начиная с версии 4.0, для повышения быстродействия допускается непосредственное взаимодействие драйвера с аппаратурой. Модуль уровня аппаратных абстракций требует перенастройки при изменении конфигурации оборудования.

4.2 Ядро и планирование процессов

Ядро осуществляет планирование действий процессора и синхронизацию работы процессов и нитей. Ядро является резидентным и непрерываемым. Ядро объектно-базировано, то есть обеспечивает низкоуровневую базу для определенных объектов ОС, которые могут использоваться компонентами высшего уровня. Объекты ядра делятся на две группы: объекты управления и объекты диспетчеризации. Основным оъектом управления является процесс, представляющий собой адресное пространство, набор доступных процессу объектов и совокупность нитей управления. Некоторые другие объекты управления: прерывание, процедура синхронного вызова, процедура отложенного вызова и т.д. Объекты диспетчеризации характеризуются сигнальными состояниями и управляют диспетчеризацией и синхронизацией операций. Примеры объектов диспетчеризации: нить, семафор, событие, взаимное исключение (mutex - для пользовательского режима и mutant - для режима ядра) и другие.

Ядро реализует основную политику планирования процессов и нитей (хотя в нее могут быть внесены изменения серверами подсистем). Всего в Windows NT имеется 32 градации приоритетов, разнесенные по 4 классам. При запуске процесс получает уровень приоритета, назначаемый по умолчанию его классу:

для класса реального времени - уровень 24;

для высокого класса - уровень 13;

для нормального класса - уровень 9 для интерактивного или уровень 7 для фонового процесса;

для отложенного класса - уровень 4.

Общие правила диспетчеризации таковы:

на выполнение выбирается нить с наивысшим уровнем приоритета, ей выделяется квант процессорного времени;

если появляется нить с более высоким уровнем приоритета, выполнение текущей нити прерывается, текущая нить ставится в очередь готовых, при этом ее приоритет не изменяется;

если нить исчерпала выделенный ей квант времени, она прерывается и ставится в очередь готовых, при этом ее приоритет понижается;

если нить перешла в ожидание, не исчерпав выделенный ей квант времени, ее приоритет повышается.

Исполнительная подсистема - верхний уровень ядра, представляющий сервис ядра подсистемам среды и другим серверам. Ниже перечисляются компоненты исполнительной подсистемы.

Диспетчер объектов обеспечивает поддержку объектно-базированной структуры ОС, представляющей ресурсы в виде объектов - абстрактных инкапсулированных типов данных. Диспетчер Объектов выполняет общие функции управления объектами - как пользовательскими, так и объектами ОС. Все пользовательские объекты имеют внешние имена. Объекты ОС могут быть как именованными, так и неименованными, последние используются только внутри самой ОС. Именование любых объектов подчиняется общим правилам, имена объектов подобны именам файлов в иерархической структуре каталогов. Диспетчер объектов обеспечивает унифицированные правила для именования, хранения и обеспечения безопасности объектов.

Менеджер безопасности проводит политику защиты и аудита объектов на персональном компьютере (подробнее - см.ниже).

Менеджер процессов отслеживает объекты процессов и нитей. Фактически основная часть планирования процессов и нитей реализована в ядре, менеджер же процессов обеспечивает создание, уничтожение и протоколирование этих объектов, а также обеспечивает набор средств создания и использования нитей и процессов для конкретных подсистем сред. В Windows NT процессы не связываются родственными отношениями в структуру дерева (как, например, в Unix или в OS/2). Однако в Windows 2000 введен новый объект - задание, представляющий собой именованную группу процессов и позволяющий вести общее управление и учет для такой группы.

4.3 Адресные пространства

Менеджер виртуальной памяти выполняет формирование виртуального адресного пространства процесса и отображает виртуальные адреса в адресных пространствах процессов на физические страницы памяти. Структура виртуального адресного пространства пользовательского процесса показана на рисунке 4.2.

Рисунок 4.2 Виртуальное адресное пространство пользовательского процесса в Windows NT

Из 4 Гбайт виртуального адресного пространства для пользовательского процесса доступна нижняя половина за вычетом самых младших 64 Кбайт. В виртуальном адресном пространстве процесса реализована плоская модель памяти, качественно структура доступной для процесса памяти совпадает с таковой в Windows 9x, но в Windows NT адресные пространства процессов полностью изолированы друг от друга. Верхняя часть виртуального адресного пространства процесса, в которой находятся системные DLL, в Windows NT содержит не сами эти DLL, а только модули-заглушки. Обращение процесса к системе происходит в пределах адресного пространства процесса. Но такое обращение попадает к модулю-заглушке, который формирует сообщение-запрос к подсистеме-серверу на выполнение системного вызова. Средства вызова локальных процедур передают это сообщение процессу-серверу, они же передают ответ сервера в модуль-заглушку, а тот формирует отклик на системный вызов. У пользовательского процесса, таким образом, создается впечатление, что системный вызов был выполнен в пределах его адресного пространства, но если пользовательский процесс испортит верхнюю часть доступного ему адресного пространства, то он испортит только свои модули-заглушки и никак не повлияет на работу других процессов.

4.4 Ввод-вывод

Менеджер ввода-вывода обеспечивает независимый от устройств интерфейс ввода-вывода и отвечает за пересылку запросов на ввод-вывод соответствующим драйверам. Менеджер Ввода-Вывода поддерживает драйверы файловых систем, драйверы устройств и сетевые драйверы, обеспечивая для них однородную среду. Модель ввода-вывода Windows NT многоуровневая, каждый драйвер отвечает за логически законченный уровень работы. Самый нижний уровень составляют драйверы устройств. Другие драйверы являются надстройкой над драйверами устройств и не зависят от специфики работы конкретного устройства. Поддержка файловой системы отдельным драйвером в этой иерархии позволяет Windows NT работать с разными файловыми системами.

4.5 Процессы-серверы

Часть системы, работающая в пользовательском режиме, представлена процессами-серверами. Процессы-серверы выполняются каждый в своем адресном пространстве, полностью изолированном от пользовательских процессов и от других серверов. Серверу доступны все 4 Гбайта его виртуального адресного пространства. Процессы-серверы могут быть подсистемами сред или специальными серверами. Подсистемы сред обеспечивают для пользовательских процессов среды выполнения, соответствующие спецификациям тех или иных операционных систем. Подсистема работает в пользовательском режиме, но ее виртуальное адресное пространство полностью отделено от адресного пространства любого приложения. Взаимодействие между приложениями и подсистемами происходит только через вызовы локальных процедур, что делает процесс-сервер защищенным от клиентов. Основной и обязательной подсистемой является Win32, остальные среды могут устанавливаться по выбору. Подсистема Win32 обеспечивает выполнение приложений Windows NT и Windows 9x, а также эмулирует среды MS DOS и Windows 3.1. Среда Win32 обеспечивает наиболее полную функциональность, и другие серверы обращаются к ней для выполнения некоторых функций. Приложения MS DOS и Windows 3.1 выполняются в контексте процесса, являющегося Виртуальной Машиной MS DOS. Виртуальная Машина MS DOS - это процесс Win32, который эмулирует процессор Intel 8086, прерывания BIOS, прерывания MS DOS и системные функции Windows 3.1 и драйверы реального режима. Каждая Виртуальная Машина MS DOS выполняется в собственном изолированном виртуальном адресном пространстве и обеспечивает для выполняющихся в ней приложений адресное пространство, соответствующее MS DOS или Windows 3.1.

Специальными серверами являются службы Windows NT, такие как регистратор событий, подсистема безопасности, средства вызова удаленных процедур и т.п., а также компоненты промежуточного программного обеспечения фирмы Microsoft, устанавливаемые по выбору - такие как MS SQL Server, MS Transaction Server и т.п. Со временем значимость подсистем сред (кроме среды Win32) падает, так как Microsoft не ставит перед собой задачи поддержки приложений, разработанных для других сред, но значительно возрастает роль серверных процессов, в которых выполняются продукты семейства MS BackOffice.

4.6 Система безопасности

Windows NT с самого начала планировалась как многопользовательская система, поэтому средства аутентификации пользователей и авторизации доступа к ресурсам встроены в систему, в том числе, и на уровне ядра. На рисунке 4.3. показаны компоненты системы безопасности Windows NT (имеется в виду локальная безопасность, т.е. защита ресурсов на локальном компьютере).

Рисунок 4.3 Система безопасности Windows NT

Процесс входа в систему обеспечивает начало работы с системой как интерактивных пользователей, так и удаленных клиентов, обращающихся к серверу. Этот компонент не связан с безопасностью непосредственно, но обращается к Распорядителю локальной безопасности, который организует аутентификацию пользователя по имени и паролю. Бюджеты всех зарегистрированных пользователей сохраняются в Базе данных бюджетов, доступ к которой осуществляется только через Диспетчер бюджета безопасности. Кроме того, Распорядитель локальной безопасности управляет политикой локальной безопасности - разрешениями на доступ и ведет Базу данных локальной безопасности, а также управляет политикой контроля и регистрирует контрольные сообщения в Журнале безопасности.

Основную работу выполняет Менеджер безопасности в составе Исполнительной системы. Этот модуль проверяет права доступа к объектам по запросам других модулей Исполнительной системы (прежде всего - Менеджера объектов) и генерирует контрольные сообщения. Для получения информации о правах и передачи контрольных сообщений Менеджер безопасности взаимодействует с Распорядителем локальной безопасности.

При входе пользователя в систему для него на основе информации о бюджете пользователя, хранящейся в Базе данных бюджетов, создается маркер доступа, содержащий:

уникальный идентификатор безопасности пользователя;

список идентификаторов безопасности групп, в которые пользователь входит;

специальные привилегии пользователя.

Последний элемент определяет права, не связанные с отдельными объектами, например: возможность выполнять низкоуровневую отладку объектов, увеличивать приоритет процессов, изменять конфигурацию драйверов, работать с Журналом контроля и т.д. Пользователи могут входить в группы, в Windows NT существует несколько встроенных групп (например, Администраторы, Операторы сервера, Операторы архива и т.д.), которым некоторые специальные привилегии предоставляются по умолчанию.

Копия маркера доступа создается для каждого процесса данного пользователя. Однако, для работы в режиме клиент/сервер Windows NT использует так называемое воплощение прав. Суть воплощения состоит в том, что процесс-сервер (или его нить), выполняющий обслуживание клиента, выполняется с маркером доступа процесса-клиента.

Windows NT использует модель безопасности, основанную на списках контроля доступа: основная информация о возможностях доступа связывается с объектом, а не с пользователем. Все именованные и некоторые неименованные объекты имеют собственные дескрипторы безопасности в Базе данных локальной безопасности. В дескриптор безопасности входят:

идентификатор владельца объекта;

идентификаторов группы владельца (используется только для подсистемы POSIX);

контролируемый список управления доступом, определяющий, какие пользователи имеют доступ к объекту, этот список управляется владельцем объекта;

системный список управления доступом, определяющий, какие контрольные сообщения должны генерироваться для этого объекта, этот список управляется Администратором.

Контролируемый список управления доступом состоит из элементов двух типов: "доступ разрешается" и "доступ запрещается". Каждый из элементов содержит идентификатор пользователя и маску доступа, кодирующую одну или несколько возможностей для данного пользователя. Для одного пользователя может быть несколько элементов в списке, описывающих его различные возможности, при просмотре списка эти возможности накапливаются.

Каждый тип объекта может иметь до 5 специфических возможностей - операций, выполняемых только для данного типа объекта. Кроме того, имеются стандартные возможности - операции, выполняемые для объектов любого типа, а именно: