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

Содержание 

 

Введение

3

1 Основные понятия.  Архитектура ОС Windows

4

    1.1 Ядро и вспомогательные модули ОС

4

    1.2 Ядро в привилегированном режиме

6

    1.3 Многослойная структура ОС

7

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

11

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

15

    2.1 Уровень абстрагирования от оборудования

15

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

15

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

16

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

16

    2.5 Диспетчеризация  управления программами

17

3 Системный реестр Windows

22

    3.1 Использование  реестра компонентами Windows

23

    3.2 Организация системного реестра

24

    3.3 Кусты и файлы реестра

25

Заключение

26

Литература

27


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

 

Операционная система Microsoft Windows XP, создана на основе технологии NT и является прямой наследницей системы Windows 2000. Вместе с тем, все лучшие нововведения, включенные в Windows Me, можно обнаружить и в Windows XP. При сохранении высоких показателей надежности, безопасности и быстродействия, система стала более простой в освоении, в ней появилось множество средств, предназначенных для индивидуальных домашних пользователей.

Следует отметить, что  для эффективной работы с операционной системой Windows XP требуется достаточно мощный современный компьютер. Прежде всего, в компьютере должно быть установлено не менее 128 мегабайт памяти. Лучше установить 256 мегабайт, чтобы система работала быстрее. Процессор может использоваться любой, но не слишком старый. Если тактовая частота процессора не менее 300 мегагерц, то он подойдет. Хотя лучше, конечно, использовать процессор с частотой более одного гигагерца. Жесткий диск должен вмещать не только файлы операционной системы и временные файлы, но и иметь достаточно свободного места, например, для создания образа компакт-диска перед его записью. Реально требуется диск размером не менее двух-трех гигабайт. А если учесть, что на диске надо установить другие программы и оставить место для разных документов, то диск объемом 10 гигабайт нельзя назвать слишком большим.

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

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

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

1 Основные понятия

 

1.1 Ядро и вспомогательные модули ОС

 

 Наиболее общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы:

 - ядро — модули, выполняющие основные функции ОС;

 - модули, выполняющие вспомогательные функции ОС.

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

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

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

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

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

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

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

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

 Некоторая  программа может существовать определенное время как пользовательское приложение, а потом стать частью ОС, или наоборот. Ярким примером такого изменения статуса программы является Web-браузер компании Microsoft, который сначала поставлялся как отдельное приложение, затем стал частью операционных систем Windows NT 4.0 и Windows 95/98, а сегодня существует большая вероятность того, что по решению суда этот браузер снова превратится в самостоятельное приложение.

 

Рисунок 1 - Нечеткость границы между ОС и приложениями

 

 Вспомогательные модули ОС обычно подразделяются на следующие группы:

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

- системные обрабатывающие программы — текстовые или графические редакторы, компиляторы, компоновщики, отладчики;

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

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

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

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

 

 

Рисунок 2 - Взаимодействие между ядром и вспомогательными модулями ОС

 

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

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

 

1.2 Ядро в привилегированном режиме

 

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

 Обеспечить привилегии  операционной системе невозможно  без специальных средств аппаратной  поддержки. Аппаратура компьютера  должна поддерживать как минимум  два режима работы — пользовательский  режим  (user mode) и привилегированный режим, который также называют режимом ядра  (kernel mode), или режимом супервизора  (supervisor mode). Подразумевается, что операционная система или некоторые ее части работают в привилегированном режиме, а приложения — в пользовательском режиме.

 Так как  ядро выполняет все основные  функции ОС, то чаще всего именно  ядро становится той частью  ОС, которая работает в привилегированном  режиме (рис 3). Иногда это свойство — работа в привилегированном режиме — служит основным определением понятия «ядро».

 

Рисунок 3 - Архитектура операционной системы с ядром в привилегированном режиме

 

1.3 Многослойная структура ОС

 

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

 

Рисунок 4 - Трехслойная схема вычислительной системы

 

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

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

Ядро может состоять из следующих слоев:

Средства  аппаратной поддержки ОС. До сих пор об операционной системе говорилось как о комплексе программ, но, вообще говоря, часть функций ОС может выполняться и аппаратными средствами. Поэтому иногда можно встретить определение операционной системы как совокупности программных и аппаратных средств, что и отражено на рис. 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)

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