У каждого объекта Windows есть заголовок и тело объекта. Диспетчер объектов управляет заголовками объектов, а телами объектов управляют компоненты исполняющей системы, являющиеся владельцами тех типов объектов, которые ими созданы. В каждом заголовке объекта содержится также индекс на специальный объект, называемый объектом типа (type object), в котором содержится информация, общая для каждого экземпляра объекта.
Кроме того, существует до пяти дополнительных подзаголовков: информационный заголовок названия, информационный заголовок квоты, информационный заголовок процесса, информационный заголовок дескриптора и информационный заголовок создателя.
Структура объекта.
Содержание:
Заголовки и тела объектов.
Диспетчер объектов использует данные, хранящиеся в заголовке объекта для управления объектами независимо от их типа. В таблице дано краткое описание полей заголовка объекта, а в следующей таблице дано описание полей, которые могут быть в дополнительных подзаголовках объекта.
Кроме заголовка объекта, содержащего информацию, относящуюся к любым объектам, в подзаголовках содержится дополнительная информация, относящаяся к специфическим аспектам объекта. Учтите, что эти структуры находятся по переменному смещению от заголовка объекта, значение которого зависит от количества подзаголовков, связанных с основным заголовком объекта. (За исключением, как ранее указывалось, информации о создателе.)
Для каждого имеющегося подзаголовка с целью отображения его существования обновляется поле InfoMask. Когда диспетчер объектов проводит проверку заданного подзаголовка, он проверяет, выставлен ли соответствующий бит в InfoMask, а затем использует оставшиеся биты для выбора правильного смещения в таблице ObpInfoMaskToOffset, где он находит смещение подзаголовка с начала заголовка объекта.
Эти смещения существуют для всех возможных комбинаций имеющихся в наличии подзаголовков, но, поскольку подзаголовки, если присутствуют, всегда размещаются в фиксированном, постоянном порядке, для заданного заголовка количество возможных мест будет равно максимальному количеству предшествующих ему подзаголовков. Например, поскольку первым всегда следует подзаголовок с информацией об имени, у него есть только одно возможное смещение.
С другой стороны, подзаголовок с информацией о дескрипторах (который размещается третьим) имеет три возможных места, поскольку он может размещаться после подзаголовка квоты, а может и не размещаться после этого подзаголовка, который, в свою очередь, мог бы располагаться после информации об имени. Описания всех дополнительных подзаголовков объекта и их мест даны в таблице. Что касается информации о создателе, то присутствие этого подзаголовка определяется значением флагов заголовка объекта.
Поля заголовка объекта.
Каждый из этих подзаголовков является дополнительным и присутствует только при определенных обстоятельствах, либо в течение запуска системы, либо во время создания объекта. В таблице дается описание этих обстоятельств.
Дополнительные подзаголовки объекта.
И наконец, ряд атрибутов и (или) флагов определяют поведение объекта во время создания или во время определенных операций. Диспетчер объектов получает эти флаги при каждом создании нового объекта в структуре под названием атрибуты объекта. Эта структура определяет имя объекта, корневой каталог объекта, в который он должен быть вставлен, дескриптор безопасности объекта и флаги атрибутов объекта. В следующей таблице перечислены различные флаги, которые могут быть связаны с объектом.
Условия, требуемые для присутствия подзаголовков объектов.
ПРИМЕЧАНИЕ. Когда объект создается с помощью API-функций в подсистеме Windows (таких как CreateEvent или CreateFile), вызывающая программа не определяет каких-либо атрибутов объекта — DLL-библиотека подсистемы делает все закулисно. Поэтому все именованные объекты, созданные с помощью Win32, помещаются в каталог BaseNamedObjects, либо в его глобальный экземпляр, либо в экземпляр, созданный для конкретного сеанса, поскольку он является корневым каталогом объектов, определяемых Kernelbase.dll в качестве части структуры атрибутов объекта.
Флаги объектов.
| Флаг атрибутов | Флаг заголовка | Назначение |
|---|---|---|
| OBJ_INHERIT | Хранится в записи таблицы дескрипторов | Определяет, будет ли дескриптор объекта унаследован дочерними процессами, и сможет ли процесс воспользоваться функцией DuplicateHandle для создания копии |
| OBJ_PERMANENT | OB_FLAG_PERMANENT_OBJECT | Определяет способность объекта сохранять поведение, зависящее от рассматриваемых далее подсчетов ссылок |
| OBJ_EXCLUSIVE | OB_FLAG_EXCLUSIVE_OBJECT | Указывает на то, что объект может использоваться только тем процессом, который его создал |
| OBJ_CASE_INSENSITIVE | Хранится в записи таблицы дескрипторов | Указывает на то, что поиск этого объекта в пространстве имен должен вестись без учета регистра символов. Может быть отменен установкой флага case insensitive в типе объекта |
| OBJ_OPENIF | Не сохраняется, используется во время выполнения | Указывает на то, что операция создания объекта с таким же именем должна привести к открытию уже существующего объекта, а не к выдаче ошибки |
| OBJ_OPENLINK | Не сохраняется, используется во время выполнения | Указывает на то, что диспетчер объектов должен открыть дескриптор символической ссылки, а не целевого объекта |
| OBJ_KERNEL_HANDLE | OB_FLAG_KERNEL_OBJECT | Указывает на то, что дескриптор объекта должен быть дескриптором ядра (подробности будут даны чуть позже) |
| OBJ_FORCE_ACCESS_CHECK | Не сохраняется, используется во время выполнения | Указывает на то, что даже при открытии объекта из режима ядра требуется полная проверка прав доступа |
| OBJ_KERNEL_EXCLUSIVE | OB_FLAG_KERNEL_ONLY_ACCESS | Не дает процессу пользовательского режима открыть дескриптор объекта; используется для защиты раздела объектов /Device/PhysicalMey |
| Отсутствует | OF_FLAG_DEFAULT_ SECURITY_QUOTA | Указывает на то, что дескриптор безопасности объекта использует исходную квоту в 2 Кбайт |
| Отсутствует | OB_FLAG_SINGLE_HANDLE_ ENTRY | Указывает на то, что подзаголовок информации о дескрипторах содержит только одну запись и не является базой данных |
| Отсутствует | OB_FLAG_NEW_OBJECT | Указывает на то, что объект был создан, но еще не вставлен в пространство имен объектов |
| Отсутствует | OB_FLAG_DELETED_INLINE | Указывает на то, что объект удаляется через отложенное удаление рабочего потока |
Кроме заголовка у каждого объекта есть его тело, чей формат и содержимое уникальны для типа этого объекта; все объекты одного и того же типа используют один и тот же формат тела. Создавая тип объекта и предоставляя для него соответствующие службы, компонент исполняющей системы может контролировать работу с данными в телах всех объектов данного типа. Поскольку заголовок объекта имеет статический, заранее известный размер, диспетчер объектов может легко найти заголовок объекта путем простого вычитания размера заголовка из указателя на объект. Как уже ранее указывалось, для получения доступа к подзаголовку диспетчер объектов вычитает еще одно известное значение из указателя на заголовок объекта.
Благодаря нормированным структурам заголовка объекта и подзаголовков диспетчер объектов может предоставить небольшой набор служб, способный работать с атрибутами, сохраненными в любом заголовке объекта, и применимый к объектам любого типа (хотя некоторые общие службы не имеют для определенных объектов никакого смысла). Эти общие службы, часть из которых подсистема Windows делает доступной Windows-приложениям, перечислены в следующей таблице.
Хотя эти общие службы объектов поддерживаются для объектов всех типов, у каждого объекта есть свои службы создания (create), открытия (open) и запроса (query). Например, система ввода-вывода реализует службу создания файла для своих файловых объектов, а диспетчер процессов реализует службу создания процесса для своих объектов процесса.
Общие службы объекта.
Хотя может быть реализована всего одна служба создания объекта, подобная процедура была бы слишком сложной, поскольку набор параметров, необходимых для инициализации, к примеру, файлового объекта, существенно бы отличался от того набора, который понадобился бы для инициализации объекта типа «процесс». Кроме того, диспетчер объектов нес бы дополнительную нагрузку при каждом вызове потоком службы объекта на определение типа объекта, на который ссылается дескриптор, и на вызов соответствующей версии службы.