Лекция №13 Операционная система Windows по дисциплине«Операционные системы и оболочки»



Скачать 390.38 Kb.
Дата15.12.2016
Размер390.38 Kb.
Просмотров151
Скачиваний0
ТипЛекция
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
СТАВРОПОЛЬСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ
Экономический факультет

УТВЕРЖДАЮ

Заведующий кафедрой

______________________

«___»_____________2014 г.




ЛЕКЦИЯ №13 - Операционная система Windows

по дисциплине«Операционные системы и оболочки»


Тема №7

Сетевые операционные системы
для студентов специальности 230400.62–Информационные системы и технологии

ШИФР наименование



Рассмотрено УМК


" " ___________ 2014 года

протокол N ______________

Ставрополь - 2014 г.


Учебные и воспитательные цели:


  1. Дать систематизированные научные знания об архитектуре ОС Windows

Время:__________________________________________________________ 90 мин.

Учебно-материальное обеспечение:


  1. Опорная лекция.

  2. ГОС ВПО по направлению 230400.62 – Информационные системы и технологии.

  3. Рабочая программа дисциплины «Операционные системы и оболочки».

  4. Основная и дополнительная литература.

  5. Методические указания по изучению дисциплины «Операционные системы и оболочки».

  6. Комплект слайдов по Теме №7

Распределение времени


I. Вступительная часть

II. Учебные вопросы:



  1. Архитектуры операционной системы

  2. Подсистемы окружения и их DLL

  3. Библиотека системной поддержки

  4. Исполнительная система и ядро

  5. Поддержка оборудования

  6. Системные процессы

II. Заключительная часть
СОДЕРЖАНИЕ ЗАНЯТИЯ

Первый учебный вопрос - Архитектуры операционной системы

Теперь обратимся к ключевым компонентам системы, составляющим ее архитектуру. Упрощенная версия этой архитектуры показана на рис. 1. Учтите, что упрощенная схема не отражает всех деталей архитектуры (например, здесь не показаны уровни сетевых компонентов и различных типов драйверов устройств).



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

Существует четыре типа пользовательских процессов:



  • фиксированные процессы поддержки системы (systemsupportprocesses) — например, процесс обработки входа в систему и диспетчер сеансов, не являющиеся сервисами Windows (т. е. не запускаемые диспетчером управления процессами)

  • процессы сервисов (serviceprocesses) — носители Windows-сервисов вроде TaskScheduler и Spooler. Многие серверные приложения Windows, например Microsoft SQL Server и MicrosoftExchangeServer, тоже включают компоненты, выполняемые как сервисы;

  • пользовательские приложения (userapplications) — бывают шести типов: для 32-разрядной Windows, 64-разрядной Windows, 16-разрядной Windows 3.1, 16-разрядной MS-DOS, 32-разрядной POSIX и 32-разрядной OS/2;

  • подсистемы окружения (environmentsubsystems) — реализованы как часть поддержки среды операционной системы, предоставляемой пользователям и программистам. Изначально Windows NT поставлялась с гремя подсистемами окружения: Windows, POSIX и OS/2. Последняя была изъята в Windows 2000. Что касается WindowsХР, то в ней исходно поставляется только подсистема Windows — улучшенная подсистема POS1X доступна как часть бесплатного продукта Servicesfor UNIX.

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

Windows включает следующие компоненты режима ядра.



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

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

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

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

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

На рис. 2 отражена более подробная схема системной архитектуры Windows.



Рисунок 2 Подробная схема системной архитектуры Windows.


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

Имя файла

Компоненты

NioskrnI.exe

Исполнительная система и ядро

Ntkrnlpa.exe (только 32-разрядные системы)

Исполнительная система и ядро с поддержкой механизма PhysicalAddressExtension (РАЕ), позволяющего адресовать 64 Гб физической памяти

Haldll

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

Win32sk.sys

Часть подсистемы Windows, работающая в режиме ядра

Nidll.dll

Внутренние функции поддержки и интерфейсы (stubs) диспетчера системных сервисов с функциями исполнительной системы

Kcrnci32.dll, Advapi32.dll, User32.dll. Gdi32.dll

Основные DLL подсистемы Windows







Прежде чем детально рассматривать эти компоненты, давайте проясним, как достигается переносимость Windows между различными аппаратными платформами.

Переносимость.

Windowsрассчитана на разные аппаратные платформы, включая как CISC-системы Intel, так и RISC-системы. Windows NT первого выпуска поддерживала архитектуры х8б и MIPS. Спустя некоторое время была добавлена поддержка Alpha АХР производства DEC (DEC была приобретена Compaq, а позднее произошло слияние компаний Compaq и HewlettPackard). (Хотя Alpha АХР был 64-разрядным процессором, Windows NT работала с ним в 32-разрядном режиме.В ходе разработки Windows2000 была создана се 64-разрядная версия специально под Alpha АХР, но в свет она так и не вышла.) В Windows NT 3.51 ввели поддержку четвертой процессорной архитектуры — MotorolaPowerPC В связи с изменениями на рынке необходимость в поддержке MIPS и PowerPC практически отпала еще до начала разработки Windows2000. Позднее Compaq отозвала поддержку архитектуры Alpha АХР, и в Windows2000 осталась поддержка лишь архитектуры х86. В самые последние выпуски — WindowsХР и WindowsServer2003 — добавлена поддержка трех семейств 64-разрядных процессоров: IntelItanium IA-64, AMD x86-64 и Intel 64-bit ExtensionTechnology (EM64T) для x86 (эта архитектура совместима с архитектурой AMD x86-64, хотя есть небольшие различия в поддерживаемых командах). Последние два семейства процессоров называются системами с 64-разрядными.

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

Windows имеет многоуровневую структуру. Специфичные для архитектуры процессора или платформы низкоуровневые части системы вынесены в отдельные модули. Благодаря этому высокоуровневая часть системы не зависит от специфики архитектур и аппаратных платформ. Ключевые компоненты, обеспечивающие переносимость операционной системы, — ядро (содержится в файле NtoskrnI.exe) и уровень абстрагирования от оборудования (HAL) (содержится в файле Hal.dll). Функции, специфичные для конкретной архитектуры (переключение контекста потоков, диспетчеризация ловушек и др.), реализованы в ядре. Функции, которые могут отличаться на компьютерах с одинаковой архитектурой (например, в системах с разными материнскими платами), реализованы в HAL. Еще один компонент, содержащий большую долю кода, специфичного для конкретной архитектуры, — диспетчер памяти (memorymanager), но если рассматривать систему в целом, такою кода все равно немного.

Подавляющее большинство компонентов Windows написано на С и лишь часть из них — на С++. Язык ассемблера применяли только при создании частей системы, напрямую взаимодействующих с системным оборудованием (например, при написании обработчика ловушек прерываний) или требующих исключительного быстродействия (скажем, при переключении контекста). Ассемблерный код имеется не только в ядре и HAL, но и в составе некоторых других частей операционной системы: процедур, реализующих взаимоблокировку, механизма вызова локальных процедур (LPC), части подсистемы Windows, выполняемой в режиме ядра, и даже в некоторых библиотеках пользовательского режима.

Второй учебный вопрос - Подсистемы окружения и их DLL

Как показано на рис. 2. в Windows имеется три подсистемы окружения: OS/2, POSIX и Windows. Как мы уже говорили, подсистема OS/2 была удалена в Windows 2000. Начиная с Windows ХР. базовая подсистема POSIX не поставляется с Windows, но ее гораздо более совершенную версию можно получить бесплатно как часть продукта Servicesfor UNIX.

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

Стартовая информация подсистемы хранится в разделе реестра HKLM\ SYSTEM\CurrentControlSet\Control\SessionManager\SubSystcms.

Значением параметра Required является список подсистем, загружаемых при запуске системы. Параметр состоит из двух строк: Windows и Debug. В параметре Windows указывается спецификация файла подсистемы Windows, Csrss.exe (аббревиатура от Client/ServerRun-TimeSubsystem; см. примечание ниже). Параметр Debug остается незаполненным (он используется для внутреннего тестирования) и не выполняет никаких функций. Параметр Optional указывает, что подсистемы OS/2 и POSIX запускаются по требованию. Параметр Kmode содержит имя файла той части подсистемы Windows, которая работает в режиме ядра. — Win32k.sys.

Подсистемы окружения предоставляют прикладным программам некое подмножество базовых сервисов исполнительной системы Windows. Каждая подсистема обеспечивает доступ к разным подмножествам встроенных сервисов Windows. Это значит, что приложения, созданные для одной подсистемы, могут выполнять операции, невозможные в другой подсистеме. Так, Windows-приложения не могут использовать Р051Х-функцию fогk.

Каждый исполняемый образ (ЕХЕ) принадлежит одной — и только одной — подсистеме. При запуске образа код, отвечающий за создание процесса, получает тип подсистемы, указанный в заголовке образа, и уведомляет соответствующую подсистему о новом процессе. Тип указывается спецификатором /SUBSYSTEM в команде linkв MicrosoftVisual С++; его можно просмотреть с помощью утилиты Exetype, входящей в состав ресурсов Windows.

ПРИМЕЧАНИЕ Процесс подсистемы Windows назван Csrss.exe потому, что в WindowsNT все подсистемы изначально предполагалось выполнять как потоки внутри единственного общесистемного процесса. Когда подсистемы POSIX и OS/2 были выделены в собственные процессы, имя файла процесса подсистемы Windows осталось прежним.

Смешивать вызовы функций разных подсистем нельзя. Иными словами, приложения POSIX могут вызывать только сервисы, экспортируемые подсистемой POSIX, а приложения Windows — лишь сервисы, экспортируемые подсистемой Windows. Как вы еще убедитесь, это ограничение послужило одной из причин, по которой исходная подсистема POSIX, реализующая весьма ограниченный набор функций (только POSIX 1003-1), не стала полезной средой для переноса в нее UNIX-приложений.

Пользовательские приложения не могут вызывать системные сервисы Windows напрямую. Вместо этого они обращаются к DLL подсистем. Эти DLL предоставляют документированный интерфейс между программами и вызываемой ими подсистемой. Так, DLL подсистемы Windows (Kernel32.dll, Advapi32.dll, User32.dll и Gdi32.dll) реализуют функции WindowsAPI. DLL подсистемы POSIX (Psxdll.dll) реализует POSIXAPI.

При вызове приложением одной из функций DLL подсистемы возможно одно из трех.

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

Функция требует одного или более вызовов исполнительной системы Windows. Например, Windows-функции ReadFileи WriteFileобращаются к внутренним недокументированным сервисам ввода-вывода — соответственно к NtReadFileи NtWriteFile.

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

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

Подсистема Windows.

Эта подсистема состоит из следующих основных элементов.

Процесса подсистемы окружения (Gsrss.exe), предоставляющего:



  • поддержку консольных (текстовых) окон;

  • поддержку создания и удаления процессов и потоков;

  • частичную поддержку процессов 16-разрядной виртуальной DOS-машины (VDM);

  • множество других функций, например GetTempFile, DejineDosDevice, ExitWindoiusEx, а также несколько функций поддержки естественных языков.

Драйвера режима ядра (Win32k.sys), включающего:

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

  • GraphicsDeviceInterface (GDI), который представляет собой библиотеку функций для устройств графического вывода. В GDI входят функции для манипуляций с графикой и отрисовки линий, текста и фигур.

DLL-модулей подсистем (KerncI32.dll, Advapi32.dll, User32.dll и Gdi32.dll), транслирующих вызовы документированных функций Windows API в вызовы соответствующих (и в большинстве своем недокументированных) сервисов режима ядра из Ntoskrnl.exe и Win32k.sys.

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

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

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

До Windows NT 4 диспетчер окон и графические сервисы были частью процесса подсистемы Windows пользовательского режима. В Windows NT 4 основная часть кода, ответственного за обработку окон и графики, перенесена из контекста процесса подсистемы Windows в набор вызываемых сервисов, выполняемых в режиме ядра (в файл Win32k.sys). Этот перенос был осуществлен в основном для повышения общей производительности системы. Отдельный серверный процесс, содержащий графическую подсистему, требовал многочисленных переключений контекста потоков и процессов, что отнимало большое количество тактов процессора и значительные ресурсы памяти, даже несмотря на высокую оптимизацию исходной архитектуры этой подсистемы.

Например, каждый клиентский поток обслуживается парным серверным потоком в процессе подсистемы Windows, ожидающем запросов от клиентского потока. Для передачи сообщений между потоками используется специальный механизм взаимодействия между процессами, так называемый быстрый LPC (fast IPC). В отличие от обычного переключения контекста потоков передача данных между парными потоками через быстрый I.PC не вызывает в ядре события перепланирования, что позволяет серверному потоку* выполняться в течение оставшегося кванта времени клиентского потока (вне очереди, определенной планировщиком). Более того, для быстрой передачи больших структур данных, например битовых карт, используются разделяемые буферы памяти, и клиенты получают прямой доступ (только для чтения) к ключевым структурам данных сервера, а это сводит к минимуму необходимость в частом переключении контекста между клиентами и сервером Windows.

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

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

Подсистема POSIX

POSIX, название которой представляет собой аббревиатуру от «portableoperatingsysteminterfacebasedonUNIX» (переносимый интерфейс операционной системы на основе UNIX), — это совокупность международных стандартов на интерфейсы операционных систем типа UNIX. Стандарты POSIX стимулировали производителей поддерживать совместимость реализуемых ими UNIX-подобных интерфейсов, тем самым позволяя программистам легко переносить свои приложения между системами.

В Windows реализован лишь один из многих стандартов POSIX, а именно POSIX. I. который официально называется ISO/IEC 9945-1:1990, или IEEEPOSIX стандарта 1003.1-1990. Этот стандарт изначально был включен в основном для соответствия требованиям правительства США, установленным во второй половине 80-х годов. В федеральном стандарте FederalInformationProcessingStandard (FIPS) 151-2, разработанном государственным институтом стандартов и технологий (NIST), содержится требование совместимости с POSIX 1. WindowsNT 3.5» 3.51 и 4 прошли тестирование на соответствие FIPS 151-2.

Поскольку совместимость с POSIX. 1 была одной из обязательных целей, в Windows включена необходимая базовая поддержка подсистемы POSIX. 1 — например, функция/ог&, реализованная в исполнительной системе Windows, и поддержка файловой системой Windows жестких файловых связей (hardfilelinks). Однако POSIX. 1 определяет лишь ограниченный набор сервисов (управление процессами, взаимодействие между процессами, простой символьный ввод-вывод и т.д.), и поэтому подсистема POSIX в Windows не является полноценной средой программирования. Так как вызов функций из разных подсистем Windows невозможен, набор функций, доступный приложениям POSIX по умолчанию, строго ограничен сервисами, определяемыми POSIX. 1. Смысл этих ограничений в следующем: приложение POSIX не может создать поток или окно в Windows, а также использовать RPC или сокеты.

Для преодоления этого ограничения предназначен продукт MicrosoftWindowsServicesforUNIX, включающий (в версии 3.5) улучшенную подсистему окружения POSIX, которая предоставляет около 2000 функций UNIX и 300 инструментов и утилит в стиле UNIX. (Детали см. на wtvwmicrosoft.com/ uindows/sfu/ctefault.asp).

Эта улучшенная подсистема POSIX реально помогает переносить UNIX-приложения в Windows. Однако, поскольку эти программы все равно связаны с исполняемыми файлами POSIX, Windows-функции им нелосгупнм. Чтобы UNIX-приложения, переносимые в Windows, могли использовать Windows-функции, нужно приобрести специальные пакеты для переноса UNIX-программ в Windows, подобные продуктам MKSToolkit, разработанные компанией MorticeKernSystemsInc. (www.mkssoftware.com). Тогда UNIX-приложения можно перекомпилировать и заново собрать как исполняемые файлы Windows и начать постепенный переход на «родные» Windows-функции.



Третий учебный вопрос - Библиотека системной поддержки

Ntdll.dll — специальная библиотека системной поддержки, нужная в основном при использовании DLL подсистем. Она содержит функции двух типов:



  • интерфейсы диспетчера системных сервисов (systemservicedispatchstubs) к сервисам исполнительной системы Windows;

  • внутренние функции поддержки, используемые подсистемами, DLL подсистем и другими компонентами операционной системы.

Первая группа функций предоставляет интерфейс к сервисам исполнительной системы Windows, которые можно вызывать из пользовательского режима. Таких функций более 200, например NtCreateFUe, NtSelEventи т. д. Как уже говорилось, большинство из них доступно через WindowsAPI (однако некоторые из них предназначены только для применения внутри самой операционной системы).

Для каждой из этих функций в Ntdll существует точка входа с тем же именем. Код внутри функции содержит специфичную для конкретной аппаратной архитектуры команду перехода в режим ядра для вызова диспетчера системных сервисов (о нем рассказывается в главе 3), который после проверки некоторых параметров вызывает уже настоящий сервис режима ядра из Ntoskrnl.exe.

Ntdll также включает множество функций поддержки, например загрузчик образов (функции, имена которых начинаются с Ldf), диспетчер куч, функции для взаимодействия с процессом подсистемы Windows (функции, имена которых начинаются с Csr), а также универсальные процедуры библиотек периода выполнения (функции, имена которых начинаются с Rtl).Там же находится диспетчер АРС (asynchronousprocedurecall) пользовательского режима и диспетчер исключений.

Четвертый учебный вопрос - Исполнительная система и ядро

Исполнительная система (executive) находится на верхнем уровне Ntoskrnl.exe (ядро располагается на более низком уровне). В ее состав входят функции следующего типа.

Экспортируемые функции, доступные для вызова из пользовательского режима. Эти функции называются системными сервисами и экспортируются через Ntdll. Большинство сервисов доступно через WindowsAPI или API других подсистем окружения. Однако некоторые из них недоступны через документированные функции (примером могут служить LPC, функции запросов вроде NtQuerylnformatiotiProcess, специализированные функции типа NtCreatePagingFiteи т. д.).

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

Экспортируемые функции, доступные для вызова только из режима ядра и документированные в WindowsDDK или WindowsInstallableFileSystem (IFS) Kit (см. www.microsofl.com/tvhdc/ddk/ifskitxiefault.mspx).

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

Функции, определенные как глобальные, но не экспортируемые символы. Включают внутренние функции поддержки, вызываемые в Ntoskrni; их имена начинаются с lop(функции поддержки диспетчера ввода-вывода) или с Mi(функции поддержки управления памятью).

Внутренние функции в каком-либо модуле, не определенные как глобальные символы.

Исполнительная система состоит из следующих основных компонентов.

Диспетчер конфигурации, отвечающий за реализацию и управление системным реестром.

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

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

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

Диспетчер PlugandPlay, определяющий, какие драйверы нужны для поддержки конкретного устройства, и загружающий их. Требования каждого устройства в аппаратных ресурсах определяются в процессе перечисления. В зависимости от требований каждого устройства диспетчер РпР распределяет такие ресурсы, как порты ввода-вывода, IRQ, каналы DMA и области памяти. Он также отвечает за посылку соответствующих уведомлений об изменениях в аппаратном обеспечении системы (при добавлении или удалении устройств).

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

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

Ядро


Ядро состоит из набора функций в Ntoskrnl.exe, предоставляющих фундаментальные механизмы (в том числе планирования потоков и синхронизации), которые используются компонентами исполнительной системы и низкоуровневыми аппаратно-зависимыми средствами поддержки (диспетчеризации прерываний и исключений), различными в каждой процессорной архитектуре. Код ядра написан в основном на С, а ассемблер использовали лишь для решения специфических задач, трудно реализуемых на С.

Объекты ядра

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

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

Одна из групп объектов ядра, называемых управляющими (controlobjects), определяет семантику управления различными функциями операционной системы. В эту группу входят объекты АРС, DPC (deferredprocedurecall) и несколько объектов, используемых диспетчером ввода-вывода (например, объект прерывания).

Другая группа объектов под названием объекты диспетчера (dispatcherobjects) реализует средства синхронизации, позволяющие изменять планирование потоков. В группу таких объектов входят поток ядра (kernelthread), мьютекс (mutex), событие (event), семафор (semaphore), таймер (timer), ожидаемый таймер (waitabletimer) и некоторые другие. С помощью функций ядра исполнительная система создает объекты ядра, манипулирует ими и конструирует более сложные объекты, предоставляемые в пользовательском режиме.

Пятый учебный вопрос - Поддержка оборудования

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

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

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

В ядре также содержится небольшая порция кода с х86-специфичными интерфейсами, необходимыми для поддержки старых программ MS-DOS. Эти интерфейсы не являются переносимыми в том смысле, что их нельзя вызывать на машине с другой архитектурой, где они попросту отсутствуют. Этот х86-специфичный код, например, поддерживает манипуляции с GDT (globaldescriptortables) и LDT (localdescriptortables) — аппаратными средствами x86.

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

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

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

Одной из важнейших особенностей архитектуры Windows является переносимость между различными аппаратными платформами. Ключевой компонент, обеспечивающий такую переносимость, — уровень абстрагирования от оборудования (hardwareabstractionlayer.HAL).HAL — это загружаемый модуль режима ядра (Hal.dll), предоставляющий низкоуровневый интерфейс с аппаратной платформой, на которой выполняется Windows. Он скрывает от операционной системы специфику конкретной аппаратной платформы, в том числе ее интерфейсов ввода-вывода, контроллеров прерываний и механизмов взаимодействия между процессорами, т. е. все функции, зависимые от архитектуры и от конкретной машины.

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

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

Драйверы устройств являются загружаемыми модулями режима ядра (как правило, это файлы с расширением .sys); они образуют интерфейс между диспетчером ввода-вывода и соответствующим оборудованием. Эти драйверы выполняются в режиме ядра в одном из трех контекстов:



  • в контексте пользовательского потока, инициировавшего функцию ввода-вывода;

  • в контексте системного потока режима ядра;

  • как результат прерывания (а значит, не в контексте какого-либо процесса или потока, который был текущим на момент прерывания).

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

Драйверы аппаратных устройств, которые управляют (через HAL) оборудованием, записывают на них выводимые данные и получают вводимые данные от физического устройства или из сети. Есть множество типов таких драйверов — драйверы шин, интерфейсов, устройств массовой памяти и т. д.

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

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

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

Драйверы протоколов, реализующие сетевые протоколы вроде TCP/IP, NetBEUI и IPX/SPX.

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

Шестой учебный вопрос - Системные процессы

В каждой системе Windows выполняются перечисленные ниже процессы. (Два из них.Idle и System, не являются процессами в строгом смысле этого слова, поскольку они не выполняют какой-либо код пользовательского режима.)



  • Процесс Idle (включает по одному потоку на процессор для учета времени простоя процессора).

  • Процесс System (содержит большинство системных потоков режима ядра).

  • Диспетчер сеансов (Smss.exe).

  • Подсистема Windows (Csrss.exe).

  • Процесс входа в систему (Winlogon.exe).

  • Диспетчер управления сервисами (Serviccs.exe) и создаваемые им дочерние процессы сервисов (например, универсальный процесс для хостинга сервисов, Svchost.exe).

  • Серверный процесс локальной аутентификации (Lsass.exe).

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

Процесс System и его потоки

Процесс System (с идентификатором 8 в Windows 2000 и идентификатором 4 в WindowsХР и WindowsServer 2003) служит носителем особых потоков, работающих только в режиме ядра, — системных потоков режима ядра (kernel-modesystemthreads). У системных потоков имеются все атрибуты и контексты обычных потоков пользовательского режима (например, контекст оборудования, приоритет и т. д.), но они отличаются тем, что выполняются только в режиме ядра внутри системного кода, загруженного в системное пространство, — будь то Ntoskrnl.exe или какой-либо драйвер устройства. Кроме того, у системных потоков нет адресного пространства пользовательского процесса, и поэтому нужная им динамическая память выделяется из куч памяти операционной системы, например из пула подкачиваемых или нсподкачивасмых страниц.

Системные потоки создаются функцией PsCreateSystemThread(документирована в DDK), вызываемой только в режиме ядра. Windows, как и драйверы устройств, создаст системные потоки при инициализации системы для выполнения действий, требующих получения контекста потока, например для выдачи и ожидания запросов на ввод-вывод или опроса устройства. Скажем, диспетчер памяти использует системные потоки для реализации таких функций, как запись измененных страниц в страничный файл (pagefile) или в спроецированные файлы, загрузки процессов в память или выгрузки из нее и т. д. Ядро создает системный поток под названием «диспетчер настройки баланса» (balancesetmanager), активизируемый раз в секунду для инициации при необходимости различных событий, связанных с планированием и управлением памятью. Диспетчер кэша также использует системные потоки для реализации как опережающего чтения, так и отложенной записи. Драйвер файл-сервера (Srv.sys) с помощью системных потоков отвечает на сетевые запросы ввода-вывода применительно к файлам на общих дисковых разделах, доступных в сети. Даже драйвер дисковода гибких дисков создаст свой системный поток для опроса этого устройства (это повышает эффективность опроса, потому что драйвер дисковода гибких дисков, управляемый прерываниями, расходует много системных ресурсов). Подробнее о конкретных системных потоках см. главы, где рассматриваются соответствующие компоненты.

По умолчанию владельцем системных потоков является процесс System, но драйверы могут создавать системные потоки в любом процессе. Например, драйвер подсистемы Windows (Win32k.sys) создаст системные потоки в процессе подсистемы Windows (Csrss.exe), чтобы облегчить доступ к данным в адресном пространстве этого процесса в пользовательском режиме.

Если вы занимаетесь поиском причин неполадок или системным анализом, полезно сопоставить выполнение индивидуальных системных потоков



Диспетчер сеансов (Smss)

Диспетчер сеансов (SessionManager) (\Windows\System32\Srnss.exe) является первым процессом пользовательского режима, создаваемым в системе. Он порождается системным потоком режима ядра, отвечающим за последний этап инициализации исполнительной системы и ядра.

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

Значительная часть сведений о конфигурации, хранящихся в реестре и используемых при инициализации Smss, находится в HKLM\SYSTEM\Curreni-ControlSei\Control\SessionManager.

После выполнения этих этапов инициализации главный поток Smss переходит к бесконечному ожиданию описателей процессов Csrss и Winlogon. Так как от них зависит функционирование Windows, при неожиданном завершении любого из них Smss вызывает крах системы (с кодом STATUSSYS-ТЕМ_ PROCESSTERMINATED, или ОхС000021А). Smss также ожидает запросы на загрузку, события отладки и запросы на запуск новых сеансов сервера терминала.

Сеанс Terminal Services создастсяSmss. Когда Smssполучаст запрос на создание сеанса, он сначала вызывает NtSetSystemlnformationс запросом на настройку сеансовых структур данных режима ядра.Это приводит к вызову внугренней функции диспетчера памяти MmSessionCreate, настраивающей виртуальное адресное пространство сеанса, которое будет содержать пул подкачиваемой памяти для сеанса и сеансовые структуры данных, создаваемые подсистемой Windows (а точнее, ее частью, работающей в режиме ядра), а также другими драйверами устройств. Затем Smss создает экземпляр Winlogon и Csrss для данного сеанса.

Winlogon, LSASS и Userinit

Процесс входа в Windows (\Windows\System32\Winlogon.exe) обрабатывает интерактивный вход пользователя в систему и выход из нес. При нажатии комбинации клавиш SAS (secureattentionsequence) Winlogonполучаст уведомление о запросе пользователя на вход в систему. По умолчанию SAS в Windows представляет собой комбинацию клавиш Ctrl+Alt+Dcl. Назначение SAS — защита пользователя от программ перехвата паролей, имитирующих процесс входа в систему, так как эту комбинацию клавиш нельзя перехватить в приложении пользовательского режима.

Идентификация и аутентификация при входе в систему реализованы в заменяемой DLL под названием GINA (GraphicalIdentificationandAuthentication). СтандартнаяGINAWindows, Msgina.dll, реализует интерфейс для входа в систему по умолчанию. Однако разработчики могут включать свои GINADLL, реализующие другие механизмы аутентификации и идентификации вместо стандартного метода Windows на основе проверки имени и пароля пользователя — например, на основе распознавания образцов голоса. Кроме того, Winlogon может загружать дополнительные DLL компонентов сетевого доступа для дальнейшей аутентификации. Эта функция позволяет нескольким компонентам доступа к сетям единовременно собирать вес необходимые регистрационные данные в процессе обычного входа в систему.

После ввода имя и пароль пользователя посылаются для проверки серверному процессу локальной аутентификации (localsecurityauthenticationserverprocess, ISASS) (\Windows\Sysiem32\Lsass.exe, описываемому в главе 8). I5ASS вызывает соответствующую функциональность (реализованную в виде DLL) для проверки соответствия введенного пароля с тем, что хранится в активном каталоге или SAM (части реестра, содержащей определения пользователей и групп).

После успешной аутентификации LSASS вызывает какую-либо функцию в мониторе состояния защиты (например, NtCreateloken), чтобы сгенерировать объект «маркер доступа* (accesstokenobject), содержащий профиль безопас-носги пользователя. Впоследствии Winlogon использует его для создания начального процесса оболочки. Информация о начальном процессе (или процессах) хранится в параметре Userinit в разделе реестра HKLM\ SOFTWARE\ Micro-soft\WindowsNT\CurrentVersion\Winlogon. (По умолчанию начальным процессом считается Userinit.exe, но в списке может быть более одного образа.)

Userinit выполняет некоторые дейсгвия по инициализации пользовательской среды (например, запускает сценарии регистрации и активизирует групповые политики), а затем ищет в реестре параметр Shell (в указанном выше разделе Winlogon) и создает процесс для запуска определенной системной оболочки (по умолчанию — Explorcr.exe). После этого процесс Userinit завершается. Вот почему для Explorcr.exe не показывается родительский процесс — он уже завершился. Иначе говоря, Explorer является «внучатым» процессом Winlogon. (Имена процессов, чьи родительские процессы уже завершены, в списке Tlist выравниваются полевому краю.)

Winlogonактивен не только при входе и выходе пользователя, но и при перехвате ввода SAS с клавиатуры. Например, когда вы нажимаете Ctrl+AIt+ Del после входа в систему, Winlogon открывает диалоговое окно WindowsSecurity (безопасность Windows), предлагающее на выбор выход из системы, запуск TaskManager, блокировку рабочей станции, завершение работы системы и т.д.

Диспетчер управления сервисами (SCM)

Вспомните, что термин «сервисы» в Windows обозначает как серверные процессы, так и драйверы устройств. В этом разделе обсуждаются сервисы, являющиеся процессами пользовательского режима. Они похожи на демоны UNIX или обособленные процессы VMS в том смысле, что могуг быть сконфигурированы на автоматический запуск при загрузке системы, не требуя интерактивного входа. Их также можно запустить вручную, например, с помощью оснастки Services (Службы) или вызовом Windows-функции StartSer-vice. Как правило, сервисы не взаимодействуют с вошедшим в систему пользователем, хотя при особых условиях это возможно.

Этими сервисами управляет специальный системный процесс, диспетчер управления сервисами (servicecontrolmanager) (\Windows\Systcm32\Scrvi-ces.exe), отвечающий за запуск, остановку процессов сервисов и взаимодействие с ними. Сервисы представляют собой просто Windows-образы исполняемых программ, вызывающие особые Windows-функции для взаимодействия с диспетчером управления сервисами и с его помощью выполняющие такие операции, как регистрация успешного запуска сервиса, ответы на запросы о состоянии, приостановку или завершение работы сервиса. Сервисы определяются в разделе реестра HKLM\SYSTEM\CurrcntControlSct\Scrviccs. Сведения о подразделах и параметрах, относящихся к сервисам, см. в справочном файле Rcgcntry.chm в ресурсах Windows.

Учтите, что у сервисов есть три имени: имя процесса, выполняемого в системе, внутреннее имя в реестре и так называемое отображаемое имя (displayname), которое можно увидеть в оснастке Services (Службы). (Не у каждого сервиса есть отображаемое имя, и в случае его отсутствия используется внутреннее имя.) Сервисы Windows также содержат поле описания, где находится более подробная информация о том.что делает конкретный сервис

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

Вопросы для самопроверки:


  1. Назовите типы пользовательских процессов

  2. Назовите компоненты ядра ОС Windows

  3. Функции подсистем окружения?

  4. Библиотека системной поддержки

  5. Исполнительная система и ядро

  6. Поддержка оборудования

  7. Системные процессы

Список литературы:



  1. Сетевые операционные системы/ В.Г. Олифер, Н.А. Олифер. – СПб.: Питер, 2009. - 672 с.: ил.

  2. Операционные системы: Учебник для вузов. 2-е изд. /А.В. Гордеев. – СПб.: Питер, 2006. - 416 с.: ил.

Лекцию разработал

Доцент кафедры «Информационных систем»

к.т.н., Д. Резеньков


«___»__________________2014 г.


Каталог: company -> personal -> user -> 11576 -> files -> element -> historyget
historyget -> Лекция №7 по дисциплине«Операционные системы и оболочки» Тема №5 Управление памятью для студентов специальности 230400. 62-Информационные системы и технологии шифр наименование
historyget -> Лекция №3 по дисциплине«Операционные системы» Тема №3 Архитектура операционной системы для студентов специальности 080500. 62-Бизнес-информатика шифр наименование
historyget -> Лекция №2 по дисциплине«Операционные системы» Тема №2 Операционные оболочки и среды для студентов специальности 080500. 62 Бизнес-информатика шифр наименование
files -> Лекция №10 Реестр операционной системы Windows по дисциплине«Операционные системы и оболочки» Тема №6 Файловая система ос для студентов специальности 230400. 62-Информационные системы и технологии шифр наименование
historyget -> Лекция №1 по дисциплине «Операционные системы и оболочки» Тема №1 Введение в операционные системы для студентов специальности 230400. 62 -информационные системы и технологии
historyget -> Лекция №12 Средства защиты информации в сети по дисциплине«Операционные системы и оболочки» Тема №7 Сетевые операционные системы для студентов специальности 230400. 62-Информационные системы и технологии


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал