Общая архитектура windows прикладного уровня свойства api win32

Обновлено: 23.01.2025

Что такое API и что собой представляет Windows API.

Введение в API-программирование

API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

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

API операционных систем.

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

Widows API

Windows API был изначально спроектирован для использования в программах, написанных на языке C (или C++). Работа через Windows API — это наиболее близкий к системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.

Win32 – 32х разрядный API для современных версий Windows. Самая популярная ныне версия. Базовые функции этого API реализованы в DLL kernel32.dll и advapi32.dll; базовые модули GUI — в user32.dll и gdi32.dll. Win32 появился вместе с Windows NT и затем был перенесён (в несколько ограниченном виде) в системы серии Windows 9x. В современных версиях Windows, происходящих от Windows NT, работу Win32 GUI обеспечивают два модуля: csrss.exe (Client/Server Runtime Subsystem), работающий в пользовательском режиме, и win32k.sys в режиме ядра. Работу же системных Win32 API обеспечивает ядро — ntoskrnl.exe

Win64 — 64-разрядная версия Win32, содержащая дополнительные функции для использования на 64-разрядных компьютерах. Win64 API можно найти только в 64-разрядных версиях Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows Server 2008 R2 и Windows 7.

Структура API-программ

Несколько дней назад в сеть просочился образ ранней версии Windows 11. Различные издательства провели тесты по производительности и пришли к неутешительному выводу: Windows 11 в среднем работает хуже, чем Windows 10. Но расстраиваться рано! Проблемы производительности могут быть связаны с «сыростью» слитого образа и нюансами совместимости с текущими программами. Так или иначе, 24 июня состоится официальная презентация нового поколения операционных систем Windows, которая, возможно, даст ответы на многие вопросы. Если сегодня у вас есть настроение для ностальгии, предлагаем вам окунуться в мир Windows: познакомиться с историей, как менялась ось и что у нее внутри.

История Windows

В начале 80 годов прошлого века компания IBM работала над персональным компьютером на базе процессора Intel 8088. С середины 70 годов компания Microsoft была основным поставщиком Basic для восьмибитных микрокомпьютеров. Когда IBM обратилась к Microsoft для лицензирования Basic для их нового компьютера IBM PC, Microsoft согласилась, а также посоветовала обратиться к компании Digital Research для лицензирования операционной системы CP/M. Но, получилось так, что глава Digital Research не нашел в своем графике времени для встречи для IBM, и IBM снова обратилась к Microsoft, теперь уже с просьбой решить вопрос операционной системы для IBM PC. Microsoft купила клон ОС CP/M у компании Seattle Computer Products и перенесла её на IBM PC. Итоговым названием получившейся ОС стало MS-DOS 1.0.

Первые продукты с названием «Windows» от Microsoft не были операционными системами. Это были графические среды для MS-DOS. На фоне успеха, в том числе и коммерческого, пользовательского интерфейса на Apple Lisa, компания решила реализовать графический интерфейс на IBM PC с MS-DOS. В отличии от относительно дешевых IBM PC, Apple Lisa стоили дорого (почти 10 тысяч долларов), и немногие покупатели могли позволить купить их. Microsoft решила занять нишу дешевых компьютеров с графическим интерфейсом. При этом низкая стоимость достигалась экономией на комплектующих и более низкая производительность, по сравнению с Lisa, избежать не получилось. Так, в 1985, 1987 и в 1990 выходят первые три версии Windows — 1.0, 2.0 и 3.0. Причем за первые шесть месяцев после релиза Windows 3.0 было продано более 1 миллиона экземпляров. Дальнейшее развитие Windows можно разделить на два направления — Windows на базе MS-DOS и Windows на базе NT.

Windows 1.01

Windows 9x

Windows на базе MS-DOS или Windows 9x не были первыми ОС от Microsoft, но они продолжали «старые традиции» и были построены на основе 16-битного кода MS-DOS. В августе 1995 года была выпущена Windows 95 — первая система семейства Windows 9x. Она уже была полноценной операционной системой с соответствующими возможностями. Однако у системы были проблемы с безопасностью (например, не было «администратора») и с изоляцией приложений. Зависание 16-битного приложения приводило к блокировке всей системы. Проблемы со стабильностью достались и Windows 98 и Windows ME, которые отличались от выпуска 95 года рядом небольших обновлений.

Windows NT

В целом, к концу 80-х годов в Microsoft появилось понимание о необходимости разработки операционной системы не на базе MS-DOS. Параллельно с разработкой софта, связанного с MS-DOS, Microsoft наняла команду инженеров из компании DEC для разработки новой 32-битной операционной системы. Главой группы стал Дэйв Катлер — один из главных разработчиков ОС VMS. Новая система была названа NT — от сокращения New Technology. Основной упор при разработке NT делался на безопасность и надежность системы, а также на совместимость с Windows на MS-DOS. Так получилось, что опыт при разработке VMS повлиял на NT и сходство между ними стало причиной спора между DEC и Microsoft. По итогу спор был решен во внесудебном порядке.

Дэйв Катлер

Первая система Windows называлась Windows NT 3.1 и была выпущена в 1993 году. Это была первая ОС от Microsoft. Индекс 3.1 был выбран для соответствия Windows 3.1 на MS-DOS. Эта версия не имела особого успеха. Для NT требовалось больше памяти, 32-разрядных приложений на рынке было мало, возникали проблемы с совместимостью драйвером. Достичь поставленных целей смогли в NT 3.5. А первым серьезным обновлением для NT стала версия 4.0 в 96 году. Теперь эта система была мощна, надежна и безопасна, а также обеспечивала тот же интерфейс, что и Windows 95 (которая к тому моменту была чрезвычайно популярной).

Windows NT 3.1

В 2000 году вышла новая версия Windows — Windows 2000. Она развивала идеи, заложенные в системы NT. Был добавлена технология Plug-and-Play, управление электропитанием и улучшен интерфейс пользователя.

Windows 2000

Успех Windows 2000 задал вектор развития для следующего поколения — Windows XP. В «хрюшке» Microsoft улучшила совместимость, интерфейс стал более дружелюбным. Стратегия Microsoft завоевывать аудиторию уже знакомыми системами дала плоды — за несколько лет Windows XP была установлена на сотнях миллионах ПК. Эпоха MS-DOS подошла к концу.

Следующий проект Microsoft пал жертвой собственных амбиций. Через пять лет после Windows XP, в 2006 году на свет вышла Windows Vista. В ней был переделан графический интерфейс, переработаны и добавлены функциональные возможности в плане безопасности. Была улучшена производительность, надежность.

Первоначальные планы Microsoft по поводу Vista были настолько обширны, что через несколько лет после начала разработки проект пришлось сильно ограничить. Vista включала в себе 70 миллионов строк кода, часть которого составлял «причесанный» код XP. Неудача Vista отчасти с тем, что она вышла не в то время. На 2006 год пришелся бум недорогих компьютеров, которые не могли обеспечить достаточную для Vista производительность.

Windows Vista

Проблемы Vista были учтены при разработке Windows 7. Microsoft уделила большее внимание тестированию и производительности новой системы. Windows 7 быстро вытеснила Vista, а затем и XP, став самой популярной версией Windows до появления Windows 10 (сейчас Windows 7 на втором месте по популярности).

Бум смартфонов в начале 2010-х подтолкнул Microsoft к созданию операционной системы, которую можно было бы развернуть на разных устройствах: на телефонах, планшетах, приставках и т. д. В результате этой работы мир узрел Windows 8. «Восьмерка» построена на модульном подходе MinWin для получения небольшого ядра ОС, которое можно было бы расширить на линейку других типов устройств. Но аудитория встретила холодно такой подход. Многие люди критиковали «смартфоноподобный» интерфейс на ПК, отсутствие кнопки пуск. Для решения многих проблем Microsoft выпустила обновление под названием Windows 8.1, которая, помимо исправления имеющихся ошибок, добавила новые функции.

И вот, к 2015 году Microsoft выпускает Windows 10. При разработке Microsoft продолжала развитие идеи единой системы для разных устройств. В «десятке» появилась голосовая помощница Кортана, вернули меню «Пуск», улучшена системная безопасность.

Технические аспекты

Чтобы осветить все технические аспекты и тонкости операционной системы Windows понадобится не менее 1000 страниц. Для особо любопытных советуем 7-е издание «Внутреннего устройства Windows« Марка Руссиновича, специалиста по внутреннему устройству Windows. Также можно почитать «Современные операционные системы« Эндрю Таненбаума и «Operating System Concepts«: в обеих книгах есть главы, посвященные Windows. Здесь же ограничимся рассмотрением инструментов взаимодействия приложений пользователя с операционной системой (Windows API) и архитектуры «оси».

Архитектура

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

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

Упрощенная схема архитектуры Windows

Вторая линия разделяет компоненты режима ядра и гипервизор (Hyper-V). Гипервизор перехватывает многие привилегированные операции, выполняемые ядром, и эмулирует их таким образом, чтобы позволить на одной и той же машине одновременно работать нескольким операционными системам. Гипервизор работает на том же уровне привилегий процессора (0), что и ядро. Но из-за использования специализированных команд процессора (VT-x у процессоров Intel, SVM у АMD) он может изолироваться от ядра с сохранением контроля над ним и приложениями. Поэтому некоторые иногда применяют термин «кольцо -1».

Четыре базовых типа процессов пользовательского режима:

Пользовательские процессы. Эти процессы относятся к одному из следующих типов: 32- или 64-разрядные приложения Windows (приложения Windows Apps, работающие на базе среды Windows Runtime в Windows 8 и выше, включаются в эту категорию), 16-разрядные приложения Windows 3.1, 16-разрядные приложения MS-DOS, 32- и 64-разрядные приложения POSIX. Заметим, что 16-разрядные приложения могут выполняться только в 32-разрядных версиях Windows, а приложения POSIX в Windows 8 уже не поддерживаются.
Процессы служб. В эту категорию входят процессы, являющиеся хостами для служб Windows (например, службы планировщика задач и диспетчер печати). Обычно к службам предъявляется требование независимости выполнения от входа пользователя. Многие серверные приложения Windows (например, Microsoft SQL Server и Microsoft Exchange Server) также включают компоненты, выполняемые как службы.
Системные процессы. Фиксированные процессы, такие как процесс входа или диспетчер сеансов, не являются службами Windows. Другими словами, они не запускаются диспетчером служб.
Серверные процессы подсистем среды. Такие процессы реализуют часть поддержки среды ОС, предоставляемой пользователю и программисту. Изначально в Windows NT было три подсистемы среды: Windows, POSIX и OS/2. Подсистема OS/2 включалась только до Windows 2000, подсистема POSIX в последний раз была включена в Windows XP.Ultimate- и Enterprise-выпуски клиента Windows 7. Все серверные версии Windows 2008 R2 включают поддержку расширенной подсистемы POSIX, называемой SUA (Subsystem for UNIX-based Applications). Сейчас подсистема SUA не поддерживается и уже не включается как необязательное часть в версии Windows (Windows 10 версии 1607 включает подсистему Windows для Linux — WSL, Windows Subsystem for Linux).

Компоненты режима ядра:

Исполнительная система. Она содержит базовые сервисные функции ОС: управление памятью, управление процессами и потоками, безопасность, ввод/вывод, сетевая поддержка и межпроцессные коммуникации.
Ядро Windows. Низкоуровневые функции ОС: планирование потоков, диспетчеризация прерываний и исключений и многопроцессорная синхронизация. Также ядро предоставляет набор функций и базовых объектов, которые используются исполнительной системой для реализации высокоуровневых конструкций.
Драйверы устройств. Сюда входят как драйверы физических устройств, преобразующие вызовы пользовательских функций ввода/вывода в конкретные запросы ввода/вывода к устройству, так и драйверы устройств, не относящихся к физическому оборудованию, например драйверы файловой системы или сетевые драйверы.
Слой абстрагирования оборудования (HAL). Прослойка кода, изолирующее ядро, драйверы устройств и прочий исполняемый код Windows от платформенно-зависимых различий в работе оборудования, например различий между системными платами.
Оконная и графическая система. Реализация функций графического интерфейса (GUI), также известных как функции GDI: работа с окнами, элементы пользовательского интерфейса и графический вывод.
Уровень гипервизора. Включает всего-навсего один компонент: сам гипервизор. В этой среде нет ни драйверов, ни других модулей. При этом сам гипервизор состоит из нескольких внутренних уровней и служб: собственный диспетчер памяти, планировщик виртуальных процессов, управление прерываниями и таймером, функции синхронизации, разделы (экземпляры виртуальных машин) и внутрипроцессные коммуникации (IPC, Inter-Process Communication) и многие другие.

Имя файла	Компоненты
Ntoskrnl.exe	Исполнительная система и ядро
Hal.dll	HAL
Win32k.sys	Часть подсистемы Windows режима ядра (GUI)
Hvix64.exe (Intel), Hvax64.exe (AMD)	Гипервизор
.sys в \SystemRoot\System32\Drivers	Основные файлы драйверов: DirectX, Volume Manager, TCP/IP и поддержка ACPI
Ntdll.dll	Внутренние вспомогательные функции и заглушки диспетчеризации системных сервисных функций
Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll	Dll основных подсистем Windows

Windows API

Windows API (Application Programming Interface) — это программный интерфейс пользовательского режима для Windows. До появления 64-разрядной версии операционной системы программный интерфейс 32-разрядных версий Windows назывался Win32 API в отличие от исходного 16-разрядного Windows API (программный интерфейс для исходных 16-разрядных версий Windows). На данный момент термин Windows API или Win32 API относят как к 32-разрядным, так и к 64-разрядным версиям.

В «доисторические времена» Windows API состоял только из функций в стиле C. Выбор языка C был обусловлен тем, что написанный на нем код также мог использоваться из других языков. Он являлся достаточно низкоуровневым для предоставления сервиса ОС. Но огромное количество функций в сочетании с недостаточной последовательностью выбора имен и отсутствием логических группировок (вроде пространств имен C++) привели к тому, что в некоторых новых API используется другой механизм — модель COM.

WinRT

В Windows 8 появился новый API и исполнительная среда поддержки Windows Runtime (WinRT). WinRT состоит из платформенных сервисов, предназначенных для разработчиков приложений Windows Apps (приложения Windows Apps подходят для устройств, начиная от миниатюрных IoT-устройств до телефонов, планшетов, десктопных систем, ноутбуков и даже Xbox One и Microsoft HoloLens).

Содержание

Общие сведения

Windows API спроектирован для написания прикладных программ на языке С, предназначенных для работы под управлением операционной системы MS Windows. Тем не менее, API может быть использован любым языком программирования компилятора или ассемблером , способным обрабатывать (четко определенные) структуры данных низкого уровня наряду с предписанными соглашениями о вызовах для звонков и обратных вызовов . Кроме того , внутренняя реализация функции API была разработана на нескольких языках, исторически. Несмотря на то , что С не является объектно-ориентированным программированием языка, Windows API , и Windows , оба исторически были описаны как объектно-ориентированные. Там также было много классов обертки и расширений (от Microsoft и другие) для объектно-ориентированных языков программирования, которые делают эту объектно-ориентированную структуру более четко (MFC, VCL, GDI+ и т.д.) , Так , например, Microsoft Windows 8 обеспечивает API для Windows и WinRT API, который реализован в C++ и объектно-ориентированный дизайн. [Источник 2]

Работа через Windows API — это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.

Windows API представляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Си. Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие. Эти функции в свою очередь могут быть разбиты на следующие основные категории:

История Microsoft API

На протяжении многих лет были внесены различные изменения и дополнения в системах Windows , и Windows API изменился и вырос. В API для Windows 1.0 поддерживаются менее 450 функций , в то время как современные версии насчитывают тысячи. Тем не менее, в целом интерфейс остается достаточно последовательным, и старый Windows 1.0 будет по- прежнему выглядеть знакомым для программиста, который использует современный Windows API.

Одно из самых больших изменений в Windows API , был переход от Win16 (поставляется в Windows 3.1 и старше) в Win32 (Windows NT и Windows 95 и выше). В то время как Win32 первоначально была введена с Microsoft Windows NT 3.1 и Win32s разрешено использовать подмножество Win32. Для того, чтобы облегчить переход, в Windows 95, для разработчиков снаружи и внутри Microsoft ,была использована сложная схема API преобразователь , она может позволить 32-битный код для вызова в 16-битного кода (для большинства из Win16 API) , и наоборот. Плоские преобразователи позволили 32-битному коду вызывать 16-битные библиотеки, а схема широко использовалась в библиотеках Windows 95 , чтобы избежать переноса всей ОС для Win32 в одном пакете. В Windows NT, операционная система была чистой 32-битной, кроме частей для совместимости с 16-разрядными приложениями, и только родовыми преобразователями были доступны преобразователи от Win16 до Win32, как и для Windows 95. Platform SDK поставляются с компилятором , который может производить код , необходимый для этих преобразователей. Версии 64-битных ОС Windows также могут запускать 32-разрядные приложения с помощью WoW64. [Источник 4]

Обзор

Функции, предоставляемые Windows API, могут быть представлены следующим образом:

Взаимодействие программ

Версии Windows API

Почти каждая новая версия Microsoft Windows представила свои собственные дополнения и изменения в Windows API.

Win16 — первая версия Windows API для 16-разрядных версий Windows. Изначально назывался просто Windows API, затем стал называться Win16 для отличия от Win32.
Win32 — 32-разрядный API для современных версий Windows. Самая популярная ныне версия. Базовые функции этого API реализованы в динамически подключаемых библиотеках kernel32.dll и advapi32.dll ; базовые модули графического интерфейса пользователя — в user32.dll и gdi32.dll . Win32 появился вместе с Microsoft Windows NT и затем был перенесён в несколько ограниченном виде в системы серии Microsoft Windows 9x. В современных версиях Windows, происходящих от Windows NT, работу Win32 GUI обеспечивают два модуля: csrss.exe (процесс исполнения клиент-сервер), работающий в пользовательском режиме, и win32k.sys в режиме ядра. Работу же системных Win32 API обеспечивает ядро — ntoskrnl.exe .
Win32s — подмножество Win32, устанавливаемое на семейство 16-разрядных систем Microsoft Windows 3.x, и реализующее ограниченный набор функций Win32 API для этих систем.
Win64 — 64-разрядная версия Win32, содержащая дополнительные функции для использования на 64-разрядных компьютерах. Win64 API можно найти только в 64-разрядных версиях Microsoft Windows XP, Microsoft Windows Server 2003, Microsoft Windows Vista, Microsoft Windows Server 2008, Microsoft Windows Server 2008 R2, Microsoft Windows 7 и Microsoft Windows 8.
WinCE является реализацией Windows API для Windows CE операционной системы. [Источник 5]

Мультимедиа

В рамках каждой версии Windows , начиная с Microsoft Windows 95. OSR2, Microsoft предоставила Microsoft DirectX API , - набор графических и игровых услуг, который включает в себя:

- для аппаратного ускорения 2D векторной графики; - для аппаратного ускорения 3D графики; - для доступа звуковой карты низкого уровня аппаратного ускорения; - для связи с устройствами ввода, таких как джойстики и геймпады; - многопользовательская игровая инфраструктура. Этот компонент был устаревшим DirectX 9 и Microsoft больше не рекомендует использовать его для разработки игр.

Microsoft также предоставляет несколько интерфейсов API для кодирования медиа и воспроизведения:

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

На нижеприведенном рисунке представлена в обобщенном виде архитектура Windows NT. Рассмотрим некоторые из изображенных пунктов.

Режим ядра и пользовательский режим

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

Интересно, что драйверы устройств работают в режиме ядра. Это обстоятельство имеет два следствия. Во-первых, в отличие от неправильно выполняющегося приложения, неправильно работающий драйвер устройства может нарушить работу всей системы, так как он имеет доступ и ко всему системному коду и ко всей памяти. Во-вторых, прикладной программист может получить доступ к защищенным ресурсам, написав драйвер псевдоустройства (fake device), хотя это и нелегкая задача.

Термин сервис (service) имеет в среде Windows множество значений. Ниже представлены некоторые из них, имеющие отношение к рассматриваемой теме:

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

· процесс Idle, который состоит из одного потока, управляющего временем простоя процессора;

· процесс регистрации в системе — WinLogon (WINLOGON. EXE).

Можно убедиться в том, что эти системные процессы действительно выполняются в системе, посмотрев на вкладку Processes (Процессы) программы Task Manager (Диспетчер задач).

Рассмотрим некоторые из этих системных процессов.

Процесс Session Manager

Процесс WinLogon

Этот системный процесс управляет входом пользователей в систему и выходом из нее. Вызывается специальной комбинацией клавиш Windows Ctrl+Alt+Delete. WinLogon отвечает за загрузку оболочки Windows (обычно это Windows Explorer).

Процесс system

Подсистема Win32

Вызов Win32 API-функций

Когда приложение вызывает API-функцию из подсистемы Win32, может произойти одно из нескольких событий:

· если DLL подсистемы (например, USER32.DLL), экспортирующая данную API-функцию, содержит весь код, необходимый для выполнения функции то функция выполняется и возвращает результат;

· API-функции, вызываемой приложением, может потребоваться вызвать для выполнения вспомогательных действий дополнительный модуль, принадлежащий подсистеме Win32 (но не той DLL, которая экспортирует данную функцию);

· API-функции, вызываемой приложением, могут понадобиться услуги недокументированного системного сервиса. Например, чтобы создать новый процесс, API-функция CreateProcess вызывает недокументированный системный сервис NTCreateProcess для реального создания данного процесса. Это делается с помощью функций библиотеки NTDLL. DLL, которая помогает осуществлять переход из пользовательского режима в режим ядра.

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

Сервисы исполнительной системы Windows составляют низкоуровневую часть Windows NT режима ядра, включенную в файл NTOSKRNL. EXE.

· синхронизацию процессоров в многопроцессорной системе;

· создание объектов ядра.

Ниже приведены некоторые наиболее важные составляющие исполнительной системы:

Диспетчер процессов и потоков

Диспетчер виртуальной памяти

Диспетчер ввода/вывода

Диспетчер КЭШа

Диспетчер объектов

Библиотеки времени выполнения

Уровень абстрагирования от аппаратуры (HAL)

Объекты и их дескрипторы

объект Process представляет процесс; объект Thread определяет поток; объект File представляет открытый файл; объект File-mapping представляет отображаемый в память файл (memory-mapped file), то есть файл, содержимое которого отображено непосредственно на виртуальное адресное пространство и используется как физическая память; объект Pipe используется для обмена данными между процессами; объект Event является объектом синхронизации потоков, сигнализирующим о завершении операции; объект Mutex представляет собой объект синхронизации потоков, который может использоваться несколькими процессами; объект Semaphore используется для того, чтобы учитывать ресурсы и сигнализировать потоку о доступности ресурса на данный момент.

Кроме объектов ядра, существуют также пользовательские объекты и объекты GDI, такие как меню, окна, шрифты, кисти и курсоры мыши.

Дескрипторы

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

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

Подсчет используемости

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

С учетом этого ядро должно поддерживать Подсчет используемости (usage count) каждого объекта. Ядро уничтожает объект тогда, когда его используемость становится равной нулю, но не раньше. Таким образом, процесс, создавший данный объект, может закрыть (close) его дескриптор (посредством вызова API-функции CloseHandle), но объект не будет уничтожен, если какой-то другой процесс продолжает его использовать (имеет его дескриптор).

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

Совместное использование объектов несколькими процессами

Существует несколько способов совместного использования объекта несколькими процессами.

Наследование

Когда процесс (а точнее поток этого процесса) создает объект ядра, он может указать, что дескриптор этого объекта наследуется (inheritable) порожденными (child) процессами, которые данный родительский процесс создает впоследствии. В этой случае дескрипторы родительского и порожденного процессов одинаковы.

Читайте также: