stringtranslate.com

Архитектура Windows NT

Архитектура семейства операционных систем Windows NT состоит из двух уровней ( пользовательский режим и режим ядра ) со множеством различных модулей внутри обоих этих уровней.

Архитектура Windows NT , линейки операционных систем, производимых и продаваемых Microsoft , представляет собой многоуровневую конструкцию, состоящую из двух основных компонентов: пользовательского режима и режима ядра . Это вытесняющая , реентерабельная многозадачная операционная система, разработанная для работы с однопроцессорными и симметричными многопроцессорными компьютерами (SMP). Для обработки запросов ввода-вывода (I/O) он использует пакетный ввод-вывод, который использует пакеты запросов ввода-вывода (IRP) и асинхронный ввод-вывод . Начиная с Windows XP , Microsoft начала делать доступными 64-битные версии Windows; до этого существовали только 32-битные версии этих операционных систем.

Программы и подсистемы в пользовательском режиме ограничены в том, к каким системным ресурсам они имеют доступ, тогда как в режиме ядра имеется неограниченный доступ к системной памяти и внешним устройствам. Режим ядра в Windows NT имеет полный доступ к аппаратным и системным ресурсам компьютера. Ядро Windows NT является гибридным ядром ; архитектура включает простое ядро, уровень аппаратной абстракции (HAL), драйверы и ряд служб (совместно называемых Executive), которые существуют в режиме ядра. [1]

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

Исполнительные интерфейсы со всеми подсистемами пользовательского режима занимаются вводом-выводом, управлением объектами, безопасностью и управлением процессами. Ядро находится между уровнем аппаратной абстракции и исполнительной системой и обеспечивает многопроцессорную синхронизацию , планирование и диспетчеризацию потоков и прерываний, а также обработку ловушек и диспетчеризацию исключений. Ядро также отвечает за инициализацию драйверов устройств при загрузке. Драйверы режима ядра существуют на трех уровнях: драйверы самого высокого уровня, драйверы промежуточного уровня и драйверы низкого уровня. Модель драйверов Windows (WDM) существует на промежуточном уровне и в основном была разработана для обеспечения совместимости в двоичном формате и исходном коде между Windows 98 и Windows 2000 . Драйверы самого низкого уровня — это либо устаревшие драйверы устройств Windows NT, которые напрямую управляют устройством, либо могут представлять собой аппаратную шину Plug and Play (PnP).

Пользовательский режим

Пользовательский режим состоит из различных системных процессов и DLL.

Интерфейс между приложениями пользовательского режима и функциями ядра операционной системы называется «подсистемой среды». Windows NT может иметь более одного из них, каждый из которых реализует свой набор API. Этот механизм был разработан для поддержки приложений, написанных для множества различных типов операционных систем. Ни одна из подсистем среды не имеет прямого доступа к оборудованию; доступ к аппаратным функциям осуществляется путем вызова подпрограмм режима ядра. [ нужна цитата ]

Существует три основные подсистемы среды: подсистема Win32 , подсистема OS/2 и подсистема POSIX . [2]

Подсистема среды Win32

COMMAND.COM работает в NTVDM

Подсистема среды Win32 может запускать 32-разрядные приложения Windows. Он содержит консоль, а также поддержку текстовых окон, завершение работы и обработку серьезных ошибок для всех других подсистем среды. Он также поддерживает виртуальные машины DOS (VDM), которые позволяют запускать приложения MS-DOS и 16-битной Windows ( Win16 ) в Windows NT. Существует специальный VDM MS-DOS, который работает в собственном адресном пространстве и эмулирует Intel 80486 под управлением MS-DOS 5.0. Однако программы Win16 работают в VDM Win16. Каждая программа по умолчанию выполняется в одном и том же процессе, используя одно и то же адресное пространство, а VDM Win16 предоставляет каждой программе собственный поток для запуска. Однако Windows NT позволяет пользователям запускать программу Win16 в отдельном VDM Win16, что позволяет программе выполнять упреждающую многозадачность, поскольку Windows NT вытесняет весь процесс VDM, который содержит только одно работающее приложение. Процесс подсистемы среды Win32 ( csrss.exe ) также включает в себя функции управления окнами, иногда называемые « оконным менеджером ». Он обрабатывает события ввода (например, с клавиатуры и мыши), а затем передает сообщения приложениям, которым необходимо получить этот ввод. Каждое приложение отвечает за отображение или обновление своих окон и меню в ответ на эти сообщения.

Подсистема среды OS/2

Подсистема среды OS/2 поддерживает 16-битные символьные приложения OS/2 и эмулирует OS/2 1.x, но не 32-битные или графические приложения OS/2, используемые в OS/2 2.x или более поздних версиях. Только машины x86. [3] Для запуска графических программ OS/2 1.x необходимо установить дополнительную подсистему Windows NT для Presentation Manager. [3] Последней версией Windows NT, имевшей подсистему OS/2, была Windows 2000; его поддержка прекращена начиная с Windows XP. [4] [5]

Подсистема среды POSIX

Подсистема среды POSIX поддерживает приложения, написанные строго в соответствии со стандартом POSIX.1 или соответствующими стандартами ISO / IEC . Эта подсистема была заменена Interix , которая является частью служб Windows для UNIX . [4] Это, в свою очередь, было заменено подсистемой Windows для Linux .

Подсистема безопасности

Подсистема безопасности работает с токенами безопасности, предоставляет или запрещает доступ к учетным записям пользователей на основе разрешений ресурсов, обрабатывает запросы на вход в систему и инициирует аутентификацию входа в систему, а также определяет, какие системные ресурсы необходимо проверять Windows NT. [ необходима цитация ] Он также заботится об Active Directory . [ нужна цитация ] Служба рабочей станции реализует сетевой перенаправитель , который является клиентской частью Windows для совместного использования файлов и принтеров; он реализует локальные запросы к удаленным файлам и принтерам, «перенаправляя» их на соответствующие серверы в сети. [6] И наоборот, служба сервера позволяет другим компьютерам в сети получать доступ к общим файлам и общим принтерам, предлагаемым локальной системой. [7]

Режим ядра

Режим ядра Windows NT имеет полный доступ к аппаратным и системным ресурсам компьютера и запускает код в защищенной области памяти. [8] Он контролирует доступ к планированию, приоритезации потоков, управлению памятью и взаимодействию с оборудованием. Режим ядра запрещает службам и приложениям пользовательского режима получать доступ к критическим областям операционной системы, к которым у них не должно быть доступа; Процессы пользовательского режима должны попросить режим ядра выполнить такие операции от их имени.

Хотя архитектура x86 поддерживает четыре различных уровня привилегий (с номерами от 0 до 3), используются только два крайних уровня привилегий. Программы пользовательского режима запускаются с CPL 3, а ядро ​​— с CPL 0. Эти два уровня часто называют «кольцом 3» и «кольцом 0» соответственно. Такое проектное решение было принято для достижения переносимости кода на RISC- платформы, поддерживающие только два уровня привилегий, [9] , хотя это нарушает совместимость с приложениями OS/2 , которые содержат сегменты привилегий ввода-вывода, которые пытаются получить прямой доступ к оборудованию. [3]

Код, работающий в режиме ядра, включает в себя: исполнительную часть, которая сама состоит из множества модулей, выполняющих конкретные задачи; ядро , которое предоставляет низкоуровневые сервисы, используемые исполнителем; уровень аппаратной абстракции (HAL); и драйверы ядра . [8] [10]

Исполнительный

Исполнительные службы Windows составляют низкоуровневую часть режима ядра и содержатся в файле NTOSKRNL.EXE . [8] Он касается ввода-вывода, управления объектами, безопасности и управления процессами. Они разделены на несколько подсистем , среди которых Диспетчер кэша , Диспетчер конфигурации , Диспетчер ввода-вывода , Вызов локальных процедур (LPC) , Диспетчер памяти , Диспетчер объектов , Структура процесса и Монитор ссылок на безопасность (SRM) . Сгруппированные вместе компоненты можно назвать исполнительными службами (внутреннее имя Ex ). Системные службы (внутреннее имя Nt ), т. е. системные вызовы , также реализуются на этом уровне, за исключением очень немногих, которые вызываются непосредственно на уровень ядра для повышения производительности. [ нужна цитата ]

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

Каждый объект в Windows NT существует в глобальном пространстве имен . Это скриншот из Sysinternals WinObj.
Менеджер объектов
Диспетчер объектов (внутреннее имя Ob ) — это исполнительная подсистема, через которую должны пройти все остальные исполнительные подсистемы, особенно системные вызовы, чтобы получить доступ к ресурсам Windows NT, что по сути делает ее инфраструктурной службой управления ресурсами. [11] Диспетчер объектов используется для уменьшения дублирования функций управления объектными ресурсами в других исполнительных подсистемах, что потенциально может привести к ошибкам и затруднить разработку Windows NT. [12] Для менеджера объектов каждый ресурс является объектом, независимо от того, является ли этот ресурс физическим ресурсом (например, файловая система или периферийное устройство) или логическим ресурсом (например, файл). Каждый объект имеет структуру или тип объекта , о которых должен знать менеджер объектов.
Создание объекта — это процесс, состоящий из двух этапов: создание и вставка . Создание приводит к выделению пустого объекта и резервированию любых ресурсов, необходимых диспетчеру объектов, таких как (необязательное) имя в пространстве имен. Если создание прошло успешно, подсистема, ответственная за создание, заполняет пустой объект. [13] Наконец, если подсистема считает инициализацию успешной, она дает указание менеджеру объектов вставить объект , что делает его доступным через его (необязательное) имя или файл cookie, называемый дескриптором . [14] С этого момента срок жизни объекта контролируется менеджером объектов, и подсистема должна поддерживать объект в рабочем состоянии до тех пор, пока менеджер объектов не даст сигнал об его удалении. [15]
Дескрипторы — это идентификаторы, которые представляют собой ссылку на ресурс ядра через непрозрачное значение. [16] Аналогичным образом, открытие объекта по его имени подлежит проверке безопасности, но действие через существующий открытый дескриптор ограничено только уровнем доступа, запрошенным при открытии или создании объекта. [ нужна цитата ]
Типы объектов определяют процедуры объекта и любые данные, относящиеся к объекту. Таким образом, диспетчер объектов позволяет Windows NT быть объектно-ориентированной операционной системой, поскольку типы объектов можно рассматривать как полиморфные классы , определяющие объекты . Однако большинство подсистем, за заметным исключением в диспетчере ввода-вывода, полагаются на реализацию по умолчанию для всех процедур объектного типа. [ нужна цитата ]
Каждый экземпляр создаваемого объекта сохраняет его имя, параметры, передаваемые в функцию создания объекта, атрибуты безопасности и указатель на тип его объекта. Объект также содержит процедуру закрытия объекта и счетчик ссылок, который сообщает диспетчеру объекта, сколько других объектов в системе ссылается на этот объект, и тем самым определяет, может ли объект быть уничтожен, когда ему отправляется запрос на закрытие. [17] Каждый именованный объект существует в иерархическом пространстве имен объектов .
Контроллер кэша
Тесно взаимодействует с диспетчером памяти, диспетчером ввода-вывода и драйверами ввода-вывода, обеспечивая общий кэш для обычного файлового ввода-вывода. Диспетчер кэша Windows работает с блоками файлов (а не с блоками устройств) для согласованной работы между локальными и удаленными файлами и обеспечивает определенную степень согласованности с представлениями файлов, отображенными в памяти , поскольку блоки кэша являются особым случаем отображенных в памяти представлений файлов. представления и кэш пропускают особый случай ошибок страницы.
Диспетчер конфигурации
Реализует системные вызовы, необходимые реестру Windows .
Менеджер ввода-вывода
Позволяет устройствам взаимодействовать с подсистемами пользовательского режима. Он преобразует команды чтения и записи пользовательского режима в IRP чтения или записи , которые передаются драйверам устройств. Он принимает запросы ввода-вывода файловой системы и преобразует их в вызовы, специфичные для устройства, и может включать драйверы устройств низкого уровня, которые напрямую манипулируют оборудованием для чтения ввода или записи вывода. Он также включает в себя диспетчер кэша для повышения производительности диска за счет кэширования запросов на чтение и записи на диск в фоновом режиме.
Вызов локальной процедуры (LPC)
Предоставляет порты межпроцессного взаимодействия с семантикой соединения. Порты LPC используются подсистемами пользовательского режима для связи со своими клиентами, исполнительными подсистемами для связи с подсистемами пользовательского режима, а также в качестве основы для локального транспорта для Microsoft RPC .
Менеджер памяти
Управляет виртуальной памятью , контролируя защиту памяти и подкачку памяти в физическую память и из нее во вторичное хранилище, а также реализует универсальный распределитель физической памяти. Он также реализует анализатор исполняемых файлов PE, который позволяет отображать или отключать отображение исполняемого файла за один атомарный шаг.
Начиная с Windows NT Server 4.0, Terminal Server Edition, диспетчер памяти реализует так называемое сеансовое пространство — диапазон памяти режима ядра, который подлежит переключению контекста так же, как и память пользовательского режима. Это позволяет нескольким экземплярам подсистемы Win32 режима ядра и драйверам GDI работать параллельно, несмотря на недостатки их первоначальной конструкции. Каждое пространство сеанса используется несколькими процессами, которые вместе называются «сеансом».
Чтобы обеспечить определенную степень изоляции между сеансами без введения нового типа объекта, связь между процессами и сеансами обрабатывается Монитором ссылок безопасности как атрибут субъекта безопасности (токена), и его можно изменить только при наличии специальных привилегий. .
Относительно простой и разовый характер сеансов обусловлен тем, что они не были частью первоначального проекта и должны были быть разработаны с минимальным нарушением основной линии третьей стороной (Citrix Systems) в качестве предварительного условия для их продукт терминального сервера для Windows NT под названием WinFrame . Однако, начиная с Windows Vista, сеансы наконец стали полноценным аспектом архитектуры Windows. Они больше не являются конструкцией диспетчера памяти, которая косвенно проникает в пользовательский режим через Win32, а превратились в всеобъемлющую абстракцию, влияющую на большинство исполнительных подсистем. Фактически, регулярное использование Windows Vista всегда приводит к созданию многосессионной среды. [18]
Структура процесса
Управляет созданием и завершением процессов и потоков, а также реализует концепцию Job — группы процессов, которые могут быть завершены целиком или помещены под общие ограничения (например, общий максимум выделенной памяти или процессорное время). Объекты заданий были представлены в Windows 2000 .
PnP-менеджер
Обеспечивает автоматическое подключение и поддерживает обнаружение и установку устройств во время загрузки. Он также отвечает за остановку и запуск устройств по требованию — это может произойти, когда шина (например, USB или IEEE 1394 FireWire ) получает новое устройство и ей необходимо загрузить драйвер устройства для его поддержки. Его основная часть фактически реализована в пользовательском режиме, в службе Plug and Play , которая выполняет зачастую сложные задачи по установке соответствующих драйверов, уведомлению служб и приложений о прибытии новых устройств и отображению графического интерфейса пользователя.
Диспетчер питания
Обрабатывает события питания (выключение питания, режим ожидания, спящий режим и т. д.) и уведомляет затронутые драйверы с помощью специальных IRP ( Power IRP ).
Контрольный монитор безопасности (SRM)
Основной орган по обеспечению соблюдения правил безопасности встроенной подсистемы безопасности. [19] Он определяет, возможен ли доступ к объекту или ресурсу, с помощью списков управления доступом (ACL), которые сами состоят из записей управления доступом (ACE). ACE содержат идентификатор безопасности (SID) и список операций, которые ACE дает выбранной группе доверенных лиц — учетной записи пользователя, учетной записи группы или сеансу входа в систему [20] — разрешения (разрешить, запретить или проверить) для этого ресурса. [21] [22]
ГСБ
Интерфейс графического устройства отвечает за такие задачи, как рисование линий и кривых, рендеринг шрифтов и работа с палитрами. В серии выпусков Windows NT 3.x компонент GDI был помещен в подсистему выполнения клиента/сервера пользовательского режима , но в Windows NT 4.0 он был переведен в режим ядра для улучшения графической производительности. [23]

Ядро

Ядро находится между HAL и исполнительной системой и обеспечивает многопроцессорную синхронизацию, планирование и диспетчеризацию потоков и прерываний, а также обработку ловушек и диспетчеризацию исключений; он также отвечает за инициализацию драйверов устройств при загрузке, которые необходимы для запуска и работы операционной системы. То есть ядро ​​выполняет практически все задачи традиционного микроядра ; Строгое различие между Executive и Kernel является наиболее заметным остатком исходной конструкции микроядра, а в исторической проектной документации компонент ядра постоянно упоминается как «микроядро».

Ядро часто взаимодействует с диспетчером процессов. [24] Уровень абстракции таков, что ядро ​​никогда не обращается к диспетчеру процессов, а только наоборот (за исключением нескольких крайних случаев, но никогда не доходящих до функциональной зависимости).

Гибридная конструкция ядра

Дизайн Windows NT включает в себя многие из тех же целей, что и Mach , архетипическую систему микроядра, одной из наиболее важных из которых является ее структура как набора модулей, которые взаимодействуют через хорошо известные интерфейсы, с небольшим микроядром, ограниченным основными функциями, такими как первая Обработка прерываний на уровне, планирование потоков и примитивы синхронизации. Это позволяет использовать либо прямые вызовы процедур, либо межпроцессное взаимодействие (IPC) для связи между модулями и, следовательно, для потенциального расположения модулей в разных адресных пространствах (например, в пространстве ядра или в серверных процессах). Другие цели проектирования, общие с Махом, включали поддержку различных архитектур, ядро ​​с достаточно общими абстракциями, чтобы можно было реализовать поверх него несколько вариантов операционной системы, и объектно-ориентированную организацию. [25] [26]

Основной особенностью операционной системы Windows является Windows API , который всегда присутствует. Подсистема эмуляции, реализующая особенности Windows, называется подсистемой выполнения клиент/сервер (csrss.exe). В версиях NT до 4.0 этот процесс подсистемы также содержал оконный менеджер, интерфейс графического устройства и драйверы графического устройства. Однако из соображений производительности в версии 4.0 и более поздних версиях эти модули (которые часто реализуются в пользовательском режиме даже в монолитных системах, особенно в тех, которые разработаны без внутренней графической поддержки) работают как подсистема режима ядра. [25]

Приложения, работающие в NT, записываются на одну из особенностей ОС (обычно Windows API), а не на собственный NT API, документация по которому не является общедоступной (за исключением подпрограмм, используемых при разработке драйверов устройств). Личность ОС реализуется через набор библиотек DLL пользовательского режима (см. Библиотеку динамической компоновки ), которые по мере необходимости отображаются в адресные пространства процессов приложений вместе с серверным процессом подсистемы эмуляции (как описано ранее). Приложения получают доступ к системным службам, вызывая библиотеки DLL ОС, сопоставленные с их адресными пространствами, которые, в свою очередь, вызывают библиотеку времени выполнения NT (ntdll.dll), также отображаемую в адресном пространстве процесса. Библиотека времени выполнения NT обслуживает эти запросы, перехватывая их в режим ядра, чтобы либо вызвать исполнительные процедуры режима ядра, либо выполнить вызовы локальных процедур (LPC) соответствующим серверным процессам подсистемы пользовательского режима, которые, в свою очередь, используют API NT для связи с процессы приложений, подсистемы режима ядра и друг друга. [27]

Драйверы режима ядра

Windows NT использует драйверы устройств режима ядра , чтобы обеспечить взаимодействие с аппаратными устройствами . Каждый из драйверов имеет четко определенные системные и внутренние процедуры, которые он экспортирует в остальную часть операционной системы. Все устройства рассматриваются кодом пользовательского режима как файловый объект в диспетчере ввода-вывода, хотя для самого диспетчера ввода-вывода устройства рассматриваются как объекты устройств, которые он определяет как объекты файла, устройства или драйвера. Драйверы режима ядра существуют на трех уровнях: драйверы самого высокого уровня, драйверы промежуточного уровня и драйверы низкого уровня. Драйверы самого высокого уровня, такие как драйверы файловой системы для FAT и NTFS , полагаются на промежуточные драйверы. Промежуточные драйверы состоят из функциональных драйверов (или основного драйвера устройства), которые при необходимости размещаются между драйверами фильтров более низкого и более высокого уровня. Тогда функциональный драйвер полагается на драйвер шины — или драйвер, который обслуживает контроллер шины , адаптер или мост, — который может иметь дополнительный драйвер фильтра шины, который находится между ним и функциональным драйвером. Драйверы среднего уровня полагаются на работу драйверов самого низкого уровня. Модель драйверов Windows (WDM) существует на промежуточном уровне. Драйверы самого низкого уровня — это либо устаревшие драйверы устройств Windows NT, которые напрямую управляют устройством, либо аппаратная шина PnP. Эти драйверы нижнего уровня напрямую управляют оборудованием и не зависят от других драйверов.

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

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

Однако, несмотря на свое предназначение и назначенное место в архитектуре, HAL не является уровнем, который находится полностью под ядром, как ядро ​​находится ниже исполнительной системы: все известные реализации HAL в некоторой степени зависят от ядра или даже от Исполнительный. На практике это означает, что варианты ядра и HAL входят в соответствующие наборы, специально созданные для совместной работы.

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

Последовательность загрузки

Последовательность загрузки инициируется NTLDR в версиях до Vista и диспетчером загрузки Windows в Vista и более поздних версиях. [28] Загрузчик отвечает за доступ к файловой системе на загрузочном диске, запуск ntoskrnl.exe и загрузку драйверов устройств во время загрузки в память. После загрузки всех загрузочных и системных драйверов ядро ​​запускает подсистему диспетчера сеансов . Менеджер сеансов запускает важные службы ядра и пользовательского режима подсистемы Win32, такие как подсистема выполнения клиент/сервер . Сеанс также запускает процесс winlogon , позволяющий пользователям входить в систему и использовать свои учетные записи.

Смотрите также

Примечания и ссылки

Примечания
  1. ^ Finnel 2000, Глава 1: Введение в Microsoft Windows 2000, стр. 7–18.
  2. ^ «Приложение D. Запуск неродных приложений в Windows 2000 Professional». Пакет ресурсов Microsoft Windows 2000 Professional . Майкрософт . 11 сентября 2008 г.
  3. ^ abc «Комплект ресурсов для рабочей станции Windows NT, глава 28 - Совместимость с OS / 2» . Майкрософт. Архивировано из оригинала 24 октября 2012 года.
  4. ^ ab «POSIX и OS/2 не поддерживаются в Windows XP или Windows Server 2003». Майкрософт. Архивировано из оригинала 24 мая 2011 года.
  5. ↑ Райтер, Брайан (24 августа 2010 г.). «Печальная история подсистемы Microsoft POSIX».
  6. ^ «Базовая архитектура сетевого редиректора». Майкрософт. 15 декабря 2021 г. Проверено 30 июля 2023 г.
  7. ^ «Сетевая архитектура Windows NT». Майкрософт. Архивировано из оригинала 18 ноября 2016 года . Проверено 18 ноября 2016 г.
  8. ^ abc Роман, Стивен (1999). «Архитектура Windows». Программирование Win32 API с помощью Visual Basic . О'Рейли и партнеры, Inc. ISBN 1-56592-631-5.
  9. ^ «Пользователь в режиме ядра MS Windows NT и технический документ GDI» . Документация по рабочей станции Windows NT . Microsoft TechNet . Архивировано из оригинала 21 февраля 2008 года . Проверено 9 декабря 2007 г.
  10. ^ Марк Э. Руссинович; Дэвид А. Соломон; Алекс Ионеску. Внутреннее устройство Windows, пятое издание . Майкрософт Пресс. стр. 228–255.
  11. ^ Руссинович и Соломон 2005, стр. 124–125.
  12. ^ Руссинович 1997, Введение.
  13. ^ Руссинович 1997, «Типы объектов».
  14. ^ Руссинович и Соломон 2005, стр. 135–140.
  15. ^ Руссинович и Соломон 2005, стр. 141–143.
  16. ^ «Ручки и объекты». Информация о системе Windows . Майкрософт. 8 февраля 2022 г. Проверено 30 июля 2023 г.
  17. ^ Руссинович 1997, «Предметы».
  18. ^ «Влияние изоляции сеанса 0 на службы и драйверы в Windows Vista». Майкрософт. Архивировано из оригинала 27 июня 2006 года.
  19. ^ «Хранилище данных Active Directory» . Майкрософт.[ постоянная мертвая ссылка ]
  20. ^ «Определение попечителя» . MSDN. Архивировано из оригинала 8 февраля 2005 года.
  21. ^ Сиян 2000.
  22. ^ «1.2 Глоссарий». [MS-AZOD]: Обзор протоколов авторизации . 14 июня 2022 г. Вход контроля доступа (ACE).
  23. ^ «Пользователь в режиме ядра MS Windows NT и технический документ GDI» . Майкрософт. Изменение режима ядра Windows NT 4.0 . Проверено 19 января 2009 г.
  24. ^ Соломон и Руссинович 2000, стр. 543–551.
  25. ^ ab «Пользователь в режиме ядра MS Windows NT и технический документ GDI» . Корпорация Майкрософт. 2007 . Проверено 1 марта 2007 г.
  26. ^ Зильбершац, Авраам; Гэлвин, Питер Баер; Ганье, Грег (2005). Концепции операционной системы; 7-е издание (PDF) . Хобокен, Нью-Джерси: ISBN John Wiley & Sons Inc. 978-0-471-69466-3.
  27. ^ Проберт, Дэйв (2005). «Обзор архитектуры Windows». Использование проектов на основе внутренних API-интерфейсов NT для обучения принципам работы ОС . Microsoft Research/Азия – Пекин . Проверено 1 марта 2007 г.
  28. ^ «Последовательность загрузки мультизагрузки Windows — Multibooters.com» . www.multibooters.com . Проверено 19 ноября 2020 г.
Рекомендации

дальнейшее чтение

Внешние ссылки