Реализация объектов.

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

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

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

Имя объекта

Каталог, в котором живет объект

Информация о защите (кто может использовать объект)

Цена квоты (стоимость использования объекта)

Список процессов с манипуляторами (если установлен флаг отладки)

Счетчик ссылок

Указатель на объект типа

Данные, специфические для объекта

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

Подробнее цена квоты указана ниже:

Имя типа

Типы доступа

Права доступа

Стоимость квоты

Синхронизируемый?

Выгружаемый?

Метод Open Метод Close Метод Delete Метод Query name Метод Parse Метод Security

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

Подсистема Win32 отличается тем, что без нее Windows 2000 работать не может. Эта подсистема обрабатывает все, что связано с клавиатурой, мышью и экраном. Она нужна даже на серверах в отсутствии интерактивных пользователей.

В разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manadger\SubSystems записана стартовая информация. Здесь можно видеть, что параметр Requied, содержащий список подсистем, загружаемых при запуске системы, включает как требуемые две строки: Windows и Debug. В параметре Windows указывается спецификация файла, соответствующего Win32: Csrss.exe (аббревиатура от Client/Server/ Run-Time Subsystem). Это имя осталось с тех пор, как предполагалось, что подсистемы окружения будут реализованы в виде потоков (нитей) внутри одного системного процесса. Параметр Kmode содержит имя файла, той части подсистемы Win32, которая работает в режиме ядра.

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

Итак, пользовательские приложения не могут вызывать системные сервисы напрямую. Вместо этого они обращаются к DLL подсистем. Так DLL подсистемы Win32 реализуют функции Win32 API.

При вызове приложением одной из функций DLL возможно следующее развитие событий:

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

2. Вызываемая функция требует вызова одного или более сервисов исполнительной системы.

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

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