Архитектура ОС Windows

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

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

Базовые механизмы ядра. Этот слой выполняет наиболее примитивные операции ядра, такие как программное переключение контекстов процессов, диспетчеризацию прерываний, перемещение страниц из памяти на диск и обратно и т. и. Модули данного слоя не принимают решений о распределении ресурсов — они только отрабатывают принятые «наверху» решения, что и дает повод называть их исполнительными механизмами для модулей верхних слоев. Например, решение о том, что в данный момент нужно прервать выполнение текущего процесса А и начать выполнение процесса В, принимается менеджером процессов на вышележащем слое, а слою базовых механизмов передается только директива о том, что нужно выполнить переключение с контекста текущего процесса на контекст процесса В.

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

Интерфейс системных вызовов. Этот слой является самым верхним слоем ядра и взаимодействует непосредственно с приложениями и системными утилитами, образуя прикладной программный интерфейс операционной системы. Функции API, обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной и компактной форме, без указания деталей их физического расположения. Например, в операционной системе UNIX с помощью системного вызова fd = open(’7doc/a.txt", 0 RD0NLY) приложение открывает файл a.txt, хранящийся в каталоге /doc, а с помощью системного вызова read(fd, buffer, count) читает из этого файла в область своего адресного пространства, имеющую имя buffer, некоторое количество байт. Для осуществления таких комплексных действий системные вызовы обычно обращаются за помощью к функциям слоя менеджеров ресурсов, причем для выполнения одного системного вызова может понадобиться несколько таких обращений.

 

Рисунок 5 - Многослойная структура ядра ОС

 

Приведенное разбиение  ядра ОС на слои является достаточно условным. В реальной системе количество слоев и распределение функций между ними может быть и иным. В системах, предназначенных для аппаратных платформ одного типа, например ОС NetWare, слой машинно-зависимых модулей обычно не выделяется, сливаясь со слоем базовых механизмов и, частично, со слоем менеджеров ресурсов. Не всегда оформляются в отдельный слой базовые механизмы — в этом случае менеджеры ресурсов не только планируют использование ресурсов, но и самостоятельно реализуют свои планы.

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

Способ взаимодействия слоев в реальной ОС также может отклоняться от описанной выше схемы. Для ускорения работы ядра в некоторых случаях происходит непосредственное обращение с верхнего слоя к функциям нижних слоев, минуя промежуточные. Типичным примером такого «неправильного» взаимодействия является начальная стадия обработки системного вызова. На многих аппаратных платформах для реализации системного вызова используется инструкция программного прерывания. Этим приложение фактически вызывает модуль первичной обработки прерываний, который находится в слое базовых механизмов, а уже этот модуль вызывает нужную функцию из слоя системных вызовов. Сами функции системных вызовов также иногда нарушают субординацию иерархических слоев, обращаясь прямо к базовым механизмам ядра.

Выбор количества слоев ядра является ответственным и сложным делом: увеличение числа слоев ведет к некоторому замедлению работы ядра за счет дополнительных накладных расходов на межслойное взаимодействие, а уменьшение числа слоев ухудшает расширяемость и логичность системы. Обычно операционные системы, прошедшие долгий путь эволюционного развития, например многие версии UNIX, имеют неупорядоченное ядро с небольшим числом четко выделенных слоев, а у сравнительно «молодых» операционных систем, таких как Windows NT, ядро разделено на большее число слоев и их взаимодействие формализовано в гораздо большей степени.

 

1.4 Процессы, потоки и задания

 

Хотя на первый взгляд, кажется, что программа и  процесс — понятия практически  одинаковые, они фундаментально отличаются друг от друга. Программа представляет собой статический набор команд, а процесс — это контейнер для набора ресурсов, используемых при выполнении экземпляра программы. На самом высоком уровне абстракции процесс в Windows включает следующее:

закрытое виртуальное  адресное пространство — диапазон адресов виртуальной памяти, которым может пользоваться процесс;

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

список открытых описателей (handles) различных системных  ресурсов — семафоров, коммуникационных портов, файлов и других объектов, доступных  всем потокам в данном процессе;

контекст защиты (security context), называемый маркером доступа (асcess token) и идентифицирующий пользователя, группы безопасности и привилегии, сопоставленные с процессом;

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

минимум один поток.

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

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

• в саму Windows,
• в Windows Support Tools,
• Windows Debugging Tools,
• ресурсы Windows
• Platform SDK;

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

Поток (thread) — некая сущность внутри процесса, получающая процессорное время для выполнения. Без потока программа процесса не может выполняться. Поток включает следующие наиболее важные элементы:  - содержимое набора регистров процессора, отражающих состояние процессора;

- два стека,  один из которых используется  потоком при выполнении в ре-жиме  ядра, а другой — в пользовательском  режиме; закрытую область памяти, называемую локальной памятью потока (thread-local storage, TLS) и используемую подсистемами, библиотеками исполняющих систем (run-time libraries) и DLL;

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

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

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

Хотя у потоков свой контекст выполнения, каждый поток  внутри одного процесса делит его  виртуальное адресное пространство (а также остальные ресурсы, принадлежащие процессу). Это означает, что все потоки в процессе могут записывать и считывать содержимое памяти любого из потоков данного процесса. Однако потоки не могут случайно сослаться на адресное пространство другого процесса. Исключение возможно в ситуации, когда тот предоставляет часть своего адресного пространства, как раздел общей памяти (shared memory section), в Windows API называемый объектом «проекция файла» (file mapping object), или когда один из процессов имеет право на открытие другого процесса и использует функции доступа к памяти между процессами, например ReadProcessMemory и WriteProcessMemory.

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

Дескрипторы виртуальных  адресов (virtual address descriptors, VAD) — это структуры данных, используемые диспетчером памяти для учета виртуальных адресов, задействованных процессом.

 

Рисунок 6 - Процесс и его ресурсы

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 Общая структура операционной системы Windows XP

 

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

 

2.1  Уровень абстрагирования от оборудования (Hardware Abstraction Layer, HAL)

 

Его задачей является отделение операционной системы от особенностей конкретных реализаций в аппаратном обеспечении компьютера, т. е. от различий в материнских платах, в модификациях процессоров, в наборах микросхем и др. Благодаря этому уровню управление подсистемами прерываний, прямого доступа к памяти, системными шинами и таймерами для ядра операционной системы является одинаковым. Уровень HAL реализован в системном файле Hal.dll.

 

 

Рисунок 7 - Упрощенная структура Windows XP

 

2.2  Ядро операционной системы.

 

  Ядро содержит наиболее часто вызываемые низкоуровневые функции операционной системы: планирование и распределение ресурсов между процессами, их переключение и синхронизацию. В обязанности ядра входит также управление прерываниями и обработка ошибочных ситуаций при функционировании операционной системы. Код ядра Windows XP не разделяется на потоки, а находится только в оперативной памяти и не может быть выгружен на диск. Код ядра Windows XP находится в системном файле Ntoskrnl. exe. 

 

2.3 Драйверы устройств

 

Драйверы  представляют собой подпрограммы, транслирующие вызовы, поступившие от пользовательских программ в запросы обработки данных для конкретных устройств. Значительное число драйверов входит в состав Windows XP (они располагаются в подкаталоге Isystem32l drivers системного каталога и имеют тип файла *.sys, например, драйвер дисковой подсистемы находится в файле disk.sys), а для нестандартных периферийных устройств драйверы находятся в комплектах поставки.

 

2.4 Исполняющая подсистема (NT Executive)