Архитектура ос windows Основные подсистемы ос windows

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

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

Понятие пользовательского режима.

Понятие режима ядра.

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



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

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

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

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

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

Значением параметра Required является список подсистем, загружаемых при запуске системы. Параметр состоит из двух строк: Windows и Debug. В параметре Windows указывается спецификация файла подсистемы Windows, Csrss.exe (аббревиатура от Client/Server Run-Time Subsystem). Процесс подсистемы Windows назван Csrss.exe пото­му, что в Windows NT все подсистемы изначально предполагалось вы­полнять как потоки внутри единственного общесистемного процес­са. Когда подсистемы POSIX и OS/2 были выделены в собственные про­цессы, имя файла процесса подсистемы Windows осталось прежним.

Параметр Debug остается незаполненным и не выполняет никаких функций (он используется для внут­реннего тестирования).

Параметр Optional указывает, что подсистемы OS/2 и POSIX запускаются по требованию. Пара­метр Kmode содержит имя файла той части подсистемы Windows, которая работает в режиме ядра, — Win32k.sys.

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

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

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

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

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

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

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

Некоторые функции вроде CreateProcess и CreateThread могут требовать выполнения как второго, так и третьего пункта.

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

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

■ интерфейсы диспетчера системных сервисов (system service dispatch stubs) к сервисам исполнительной системы Windows;

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

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

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

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

• 
  Подсистема Windows
  
• 
  Подсистема POSIX
  
• 
  Подсистема OS/2
  

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

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

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

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

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

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

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

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

■ Graphics Device Interface (GDI) - представляет собой библиоте­ку функций для устройств графического вывода. В GDI входят функции для манипуляций с графикой и отрисовки линий, текста и фигур.

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

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

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

GDI предоставляет набор стандартных функций двухмерной графики, которые позволяют приложениям, не имеющим представления о графичес­ких устройствах, обращаться к ним. GDI-функции играют роль посредника между приложениями и драйверами дисплея и принтера. GDI интерпрети­рует запросы приложений на вывод графики и посылает соответствующие запросы драйверам. Он также предоставляет приложениям стандартный унифицированный интерфейс для использования самых разнообразных устройств графического вывода. Этот интерфейс обеспечивает независи­мость кода приложений от конкретного оборудования и его драйверов. GDI выдает свои запросы с учетом возможностей конкретного устройства, час­то разделяя запрос на несколько частей для обработки. Так, некоторые уст­ройства сами умеют формировать эллипсы, а другие требуют от GDI интер­претировать эллипсы как набор пикселов с определенными координатами. Подробнее об архитектуре подсистемы вывода графики и драйвере дисплея см. раздел «Design Guide» в книге «Graphics Drivers» из Windows DDK.

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

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

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

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

Так что же остается в той части процесса подсистемы Windows, которая работает в пользовательском режиме? Поскольку консольные программы не перерисовывают окна, все операции по отрисовке и обновлению консоль­ных и текстовых окон проводятся именно этой частью Windows. Увидеть ее деятельность несложно: просто откройте окно командной строки и перета­щите поверх него другое окно. Вы увидите, что процесс подсистемы Win­dows начинает расходовать процессорное время, перерисовывая консоль­ное окно. Кроме поддержки консольных окон, только небольшая часть Win­dows-функций посылает сообщения процессу подсистемы Windows. К ним относятся функции, отвечающие за создание и завершение процессов и по­токов, назначение букв сетевым дискам, создание временных файлов. Как правило, Windows-приложение нечасто переключает (если вообще переклю­чает) контекст в процесс подсистемы Windows.
Не пострадала ли стабильность Windows от перевода USER и GDI в режим ядра?

Некоторые интересуются, не повлияет ли на стабильность системы перевод такой значительной части кода в режим ядра. Но риск сниже­ния стабильности системы минимален. Дело в том, что до Windows NT 4 (равно как и в настоящее время) ошибка вроде нарушения доступа (access violation) в процессе подсистемы Windows пользовательского режима (Csrss.exe) приводила к краху системы, потому что процесс подсистемы Windows был и остается жизненно важным для функци­онирования всей системы. Поскольку структуры данных, определяю­щие окна на экране, содержатся именно в этом процессе, его гибель приводит к уничтожению пользовательского интерфейса. Однако да­же при функционировании Windows в качестве сервера без интерак­тивных процессов система не могла бы работать без Csrss, поскольку серверные процессы иногда используют оконные сообщения для кон­троля внутреннего состояния приложений. Так что в Windows ошиб­ки вроде нарушения доступа в том же коде, только выполняемом в ре­жиме ядра, просто быстрее приводят к краху — исключения в режиме ядра требуют прекращения работы системы.

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

Еще одно негативное последствие перевода графичес­ких драйверов в режим ядра. Ранее некоторые части графического драйвера выполнялись в Csrss, а остальные части — в режиме ядра. Те­перь весь драйвер работает только в режиме ядра. Так как не все драй­веры поддерживаемых Windows графических устройств разрабатыва­ются Microsoft, она тесно сотрудничает с производителями оборудо­вания, чтобы гарантировать разработку ими надежных и эффектив­ных драйверов. Все поставляемые с системой драйверы тестируются так же тщательно, как и другие компоненты исполнительной системы.

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

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

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

В Windows реализован лишь один из многих стандартов POSIX, а имен­но POSIX. 1.

Поскольку совместимость с POSIX. 1 была одной из обязательных целей, в Windows включена необходимая базовая поддержка подсистемы POSIX. 1 — например, функция fork, реализованная в исполнительной системе Windows, и поддержка файловой системой Windows жестких файловых связей (hard file links).

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

Для преодоления этого ограничения предназначен продукт Microsoft Windows Services for UNIX, включающий улучшенную подсис­тему окружения POSIX, которая предоставляет около 2000 функций UNIX и 300 инструментов и утилит в стиле UNIX.

Эта улучшенная подсистема POSIX помогает переносить UNIX-приложения в Windows. Однако, поскольку эти программы все равно связа­ны с исполняемыми файлами POSIX, Windows-функции им недоступны. Что­бы UNIX-приложения, переносимые в Windows, могли использовать Win­dows-функции, нужно приобрести специальные пакеты для переноса UNIX-программ в Windows. Тогда UNIX-прило­жения можно перекомпилировать и заново собрать как исполняемые фай­лы Windows и начать постепенный переход на Windows-функции.

Для компиляции и сборки приложения POSIX в Windows нужны заголовочные файлы и библиотеки POSIX из Platform SDK. Исполняе­мые файлы POSIX связываются с библиотекой подсистемы POSIX, Psxdll.dll. Поскольку Windows по умолчанию сконфигурирована на запуск подсистемы POSIX только по требованию, при первом запуске приложения POSIX должен запуститься процесс подсистемы POSIX (Psxss.exe). Его выполнение продолжается до перезагрузки системы. (Если вы завершите процесс подсистемы POSIX, запуск приложений POSIX станет невозможен до следующей перезагрузки системы.) При­ложение POSIX не выполняется самостоятельно; для него запускается специальный файл поддержки Posix.exe, создающий дочерний про­цесс, из которого и запускаются приложения POSIX.

Подсистема окружения OS/2, как и подсистема POSIX, обладает довольно ограниченной функциональностью и поддерживает лишь 16-разрядные приложения OS/2 версии 1.2 с символьным или графическим вводом-выво­дом. Кроме того, Windows запрещает прикладным программам прямой до­ступ к оборудованию и поэтому не поддерживает приложения OS/2, исполь­зующие расширенный ввод-вывод видео или включающие сегменты приви­легированного ввода-вывода, которые пытаются выполнять инструкции IN/ OUT (для доступа к некоторым аппаратным устройствам). Приложения, вы­дающие машинные команды CLI/STI, могут работать в Windows, но на вре­мя выполнения команды STI все другие приложения OS/2 в системе и пото­ки процессов OS/2, выдающих команды СLI, приостанавливаются.

Как показано на рисунке, подсистема OS/2, использующая 32-разрядное виртуальное адресное пространство Windows, может предоставить прило­жениям OS/2 версии 1.2 до 512 Мб памяти, снимая тем самым исходное ог­раничение этой версии на объем адресуемой памяти (до 16 Мб).



Мозаичная область (tiled area) — это 512 Мб заранее резервируемого виртуального адресного пространства, откуда передается и куда возвраща­ется память, выделяемая под сегменты, которыми пользуются 16-разрядные приложения. Для каждого процесса подсистема OS/2 ведет таблицу локаль­ных дескрипторов (local descriptor table, LDT), в которой сегменты разделя­емой памяти занимают один и тот же LDT-слот для всех процессов OS/2.
Потоки являются элементами вы­полняемой программы и, , подлежат планированию (подключе­нию к процессору по определенной схеме). В OS/2 всего 64 уровня приори­тетов (от 0 до 63), а в Windows — 32 (от 0 до 31). Несмотря на это, 64 уровня приоритетов OS/2 проецируются на динамические приоритеты Windows с 1-го по 15-й. Потоки OS/2, выполняемые в Windows, никогда не получают приоритеты реального времени (16-31).

Как и подсистема POSIX, подсистема OS/2 автоматически запускается при первой активизации OS/2-совместимого образа и продолжает выполняться до перезагрузки всей системы

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

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

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

■ Экспортируемые функции, доступные для вызова только из режима ядра и документированные в Windows DDK или Windows Installable File System (IFS) Kit (cm. wivivmicrosoft.com/ivhdc/ddk/ifskit.default.mspx).

■ Экспортируемые функции, доступные для вызова только из режима ядра, но не описанные в Windows DDK или IFS Kit (например, функции, кото­рые используются видеодрайвером, работающим на этапе загрузки, и чьи имена начинаются с Iribv).

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

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

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

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

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

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

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

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

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

■ Подпрограммы WDM Windows Management Instrumentation (см. главу 4), позволяющие драйверам публиковать информацию о своих рабочих ха­рактеристиках и конфигурации, а также получать команды от службы

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

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

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

■ Средство логической предвыборки (см. главу 7), ускоряющее запуск сис­темы и процессов за счет оптимизации загрузки данных, к которым про­исходит обращение при запуске системы или процессов. Кроме того, в состав исполнительной системы входят четыре основные группы функций поддержки, используемые вышеперечисленными компо­нентами. Примерно треть из них описана в DDK, поскольку драйверы тоже используют их. Вот что представляют собой четыре категории функций под­держки.

■ Диспетчер объектов — создает, управляет и удаляет объекты и абстракт­ные типы данных исполнительной системы, используемые для представ­ления таких ресурсов операционной системы, как процессы, потоки и различные синхронизирующие объекты. Подробнее о диспетчере объек­тов см. главу 3-

■ Механизм LPC (см. главу 3) — передает сообщения между клиентским и серверным процессами на одном компьютере. LPC является гибкой, оп­тимизированной версией RPC (remote procedure call), стандартного ме­ханизма взаимодействия между клиентскими и серверными процессами через сеть.

■ Большой набор стандартных библиотечных функций для обработки строк, арифметических операций, преобразования типов данных и обра­ботки структур безопасности.

■ Подпрограммы поддержки исполнительной системы, например для вы­деления системной памяти (пулов подкачиваемых и неподкачиваемых страниц), доступа к памяти со взаимоблокировкой, а также два специаль­ных типа синхронизирующих объектов: ресурс (resource) и быстродей­ствующий мьютекс (fast mutex).