Компоненты системы Windows 2000 режима пользователя.
Реализация Win API, подсистемы User, GDI, Kernel.
Microsoft Windows - семейство проприетарных операционных систем корпорации Майкрософт (Microsoft), ориентированных на применение графического интерфейса при управлении. Изначально были всего лишь графическими надстройками для MS-DOS.
В настоящее время под управлением операционных систем семейства Windows, по данным ресурса Netmarketshare (Net Applications) на 2009 год, работает около 89 % персональных компьютеров[1].
Операционные системы Windows работают на платформах x86, x86-64, IA-64, ARM. Существовали также версии для DEC Alpha, MIPS, PowerPC и SPARC[2].
Версии Microsoft Windows
Обычно все версии Windows делят на несколько «групп».
Графические интерфейсы и расширения для DOS
Эти версии Windows не были полноценными операционными системами, а являлись надстройками к операционной системе MS-DOS и были по сути многофункциональным расширением, добавляя поддержку новых режимов работы процессора, поддержку многозадачности, обеспечивая стандартизацию интерфейсов аппаратного обеспечения и единообразие для пользовательских интерфейсов программ. Предоставляли встроенные средства (GDI и USER, первые версии Windows вообще состояли из трех модулей — KERNEL, GDI и USER, первый из них предоставлял вызовы управления памятью, запуском EXE файлов и загрузкой DLL файлов, второй — графику, третий — окна) для создания графического интерфейса пользователя. Они работали с процессорами начиная с Intel 8086.
· Windows 1.0 (1985)
· Windows 2.0 (1987)
· Windows 2.1 (Windows 386) (1987) — в системе появилась возможность запуска DOS-приложений в графических окнах, причём каждому приложению предоставлялись полные 640 Кб памяти. Полная поддержка процессора 80286. Появилась поддержка процессоров 80386.
· Windows 3.0 (1990) — улучшена поддержка процессоров 80386 и защищённого режима.
· Windows 3.1 (1992) — серьёзно переработанная Windows 3.0; устранены UAE (Unrecoverable Application Errors — фатальные ошибки прикладных программ), добавлен механизм OLE, печать в режиме WYSIWYG («что видите, то и получите»), шрифты TrueType, изменён Проводник (диспетчер файлов), добавлены мультимедийные функции.
· Windows для рабочих групп (Windows for Workgroups) 3.1/3.11 — первая версия ОС семейства с поддержкой локальных сетей. В WFWG 3.11 также испытывались отдельные усовершенствования ядра, применённые позднее в Windows 95.
Семейство Windows 9x
Включает в себя Windows 95, Windows 98 и Windows Me.
Windows 95 была выпущена в 1995 году. Её отличительными особенностями являются новый пользовательский интерфейс, поддержка длинных имён файлов, автоматическое определение и конфигурация периферийных устройств Plug and Play, способность исполнять 32-битные приложения и наличие поддержки TCP/IP прямо в системе. Windows 95 использует вытесняющую многозадачность и выполняет каждое 32-битное приложение в своём адресном пространстве.
Операционные системы этого семейства не являлись безопасными многопользовательскими системами как Windows NT, поскольку из соображений совместимости вся подсистема пользовательского интерфейса и графики оставалась 16-битной и мало отличалась от той, что в Windows 3.x. Так как этот код не был thread-safe, все вызовы в подсистему оборачивались в мьютекс по имени Win16Lock, который кроме того еще и находился всегда в захваченном состоянии во время исполнения 16битного приложения. Таким образом, «повисание» 16-битного приложения немедленно блокировало всю ОС.
Программный интерфейс был подмножеством Win32 API поддерживаемым Windows NT, но имел поддержку юникода в очень ограниченном объёме[9]. Также в нём не было должного обеспечения безопасности (списков доступа к объектам и понятия «администратор»).
В составе Windows 95 присутствовал MS-DOS 7.0, однако его роль сводилась к обеспечению процесса загрузки и исполнению 16-битных DOS приложений. Исследователи заметили, что ядро Windows 95 — VMM — обращается к DOS под собой, но таких обращений довольно мало, главнейшая функция ядра DOS — файловая система FAT — не использовалась. В целом же интерфейс между VMM и нижележащей DOS никогда не публиковался, и DOS была замечена (тем же Эндрю Шульманом) в наличии недокументированных вызовов только для поддержки VMM.
Семейство Windows NT
Операционные системы этого семейства в настоящее время работают на процессорах с архитектурами x86, x64, и Itanium,ARM. Ранние версии (до 4.0 включительно) также поддерживали некоторые RISC-процессоры: Alpha, MIPS, и Power PC. Все операционные системы этого семейства являются полностью 32- или 64- битными операционными системами, и не нуждаются в MS-DOS даже для загрузки.
Только в этом семействе представлены операционные системы для серверов. До версии Windows 2000 включительно они выпускались под тем же названием, что и аналогичная версия для рабочих станций, но с добавлением суффикса, например «Windows NT 4.0 Server» и «Windows 2000 Datacenter Server». Начиная с Windows Server 2003, серверные операционные системы называются по-другому.
· Windows NT 3.1 (1993)
· Windows NT 3.5 (1994)
· Windows NT 3.51 (1995)
· Windows NT 4.0 (1996)
· Windows 2000 (2000) — Windows NT 5.0
· Windows XP (2001) — Windows NT 5.1
· Windows XP 64-bit Edition (2006) — Windows NT 5.2
· Windows Server 2003 (2003) — Windows NT 5.2
· Windows Vista (2006) — Windows NT 6.0
· Windows Home Server (2007) — Windows NT 5.2
· Windows Server 2008 (2008) — Windows NT 6.0
· Windows Small Business Server (2008) — Windows NT 6.0
· Windows 7 — Windows NT 6.1 (2009)
· Windows Server 2008 R2 — Windows NT 6.1 (2009)
· Windows Home Server 2011 — Windows NT 6.1 (2011)
· Windows 8 — Windows NT 6.2 (2012)
В основу семейства Windows NT положено разделение адресных пространств между процессами. Каждый процесс имеет возможность работать с выделенной ему памятью. Однако он не имеет прав для записи в память других процессов, драйверов и системного кода.
Семейство Windows NT относится к операционным системам с вытесняющей многозадачностью. Разделение процессорного времени между потоками происходит по принципу «карусели». Ядро операционной системы выделяет квант времени (в Windows 2000 квант равен примерно 20 мс) каждому из потоков по очереди при условии, что все потоки имеют одинаковый приоритет. Поток может отказаться от выделенного ему кванта времени. В этом случае система перехватывает у него управление (даже если выделенный квант времени не закончен) и передаёт управление другому потоку. При передаче управления другому потоку система сохраняет состояние всех регистров процессора в особой структуре в оперативной памяти. Эта структура называется контекстом потока. Сохранение контекста потока достаточно для последующего возобновления его работы.
Семейство ОС Windows Mobile для карманных компьютеров
Это семейство операционных систем реального времени было специально разработано для встраиваемых систем. Поддерживаются процессоры ARM, MIPS, SuperH и x86. В отличие от остальных операционных систем Windows, операционные системы этого семейства продаются только в составе готовых устройств, таких как смартфоны, карманные компьютеры, GPS навигаторы, MP3 проигрыватели, и другие.
В настоящее время под термином «Windows CE» понимают только ядро операционной системы. Например Windows Mobile 5.0 включает в себя ядро Windows CE 5.0, хотя в некоторых устройствах ядро Windows CE используется и без Windows Mobile.
· Windows CE
· Windows Mobile
Семейство встраиваемых ОС Windows Embedded
Windows Embedded — это семейство операционных систем реального времени, было специально разработано для применения в различных встраиваемых системах. Ядро системы имеет общее с семейством ОС Windows CE и поддерживает процессоры ARM, MIPS, SuperH и x86. Windows Embedded включает дополнительные функции по встраиванию, среди которых фильтр защиты от записи (EWF и FBWF), загрузка с флеш-памяти, CD-ROM, сети, использование собственной оболочки системы и т. п.
В отличие от операционных систем Windows, операционные системы этого семейства продаются только в составе готовых устройств, таких как: банкоматы, медицинские приборы, навигационное оборудование, «тонкие» клиенты, VoIP-терминалы, медиапроигрыватели, цифровые рамки (альбомы), кассовые терминалы, платёжные терминалы, роботы, игровые автоматы, музыкальные автоматы, и другие.
В настоящее время выпускаются следующие варианты ОС Windows Embedded:
· Windows Embedded CE,
· Windows Embedded Standard,
· Windows Embedded POSReady,
· Windows Embedded Enterprise,
· Windows Embedded NavReady,
· Windows Embedded Server.
Microsoft Windows N
Microsoft Windows N — версии Microsoft Windows, из которых корпорацией Microsoft были удалены компоненты, не совместимые с законодательством стран Европейского союза.
Структура Windows 2000/XP не отличается оригинальностью: ядро системы (исполняется на максимально приоритетном уровне процессора) и пользовательские подсистемы (исполняются на минимально приоритетном уровне).
Ядро системы является критичной частью кода, любые ошибки, происходящие в ядре, приводят к фатальному краху системы - "синему экрану". Фактически - это ошибки типа "Нарушение общей защиты". Как только код ядра начинает обращаться в запрещенные для него области памяти (попытка прочитать или записать данные, исполнить неверную инструкцию, переход на запрещенную область), срабатывает система защиты памяти процессора, и управление передается системному обработчику исключений. Обработчик исключений не может восстановить корректное поведение кода. Все, что он делает - это вывод дампа на синий экран с указанием типа ошибки и содержимого памяти в области, где сработала защита.
Пользовательские подсистемы не столь критично влияют на работу системы в целом, так как они изолированы друг от друга и от ядра средствами управления памятью и собственно процессором. Ошибки, возникающие в приложениях, исполняются на уровне пользователя, то есть на менее привилегированном уровне, нежели ядро. Поэтому, система в состоянии контролировать процесс. При возникновении же ошибки или сбоя управление передается обработчику ошибок, который называется "Doctor Watson". Он принудительно завершит приложение. Ядро системы и остальные подсистемы остаются в целости и сохранности.
Ядро Windows 2000/XP состоит из нескольких системных компонентов, каждый из которых отвечает за определенный набор задач. Основные компоненты ядра:
· Микроядро (Microkernel) - компактный код, можно сказать, сердце системы. В рамках микроядра работают ключевые службы: диспетчер памяти, диспетчер задач и другие.
· Слой абстрагирования (Hardware Abstraction Layer, HAL). Полностью абстрагирует код системы от конкретного аппаратного оборудования. Использование HAL позволяет обеспечить переносимость 99% кода системы между различным оборудованием.
· Диспетчер Ввода/Вывода (Input/Output Manager). Полностью контролирует потоки обмена между системой и устройствами. Драйверы устройств работают в контексте I/O Manager. Если драйвер написан с ошибками и может привести к сбою - это вызовет фатальный крах ядра и всей системы. 70% случаев фатальных сбоев ("синий экран") - есть результат некорректного поведения драйверов устройств.
· Windows XP содержит встроенный механизм контроля драйверов: правильно написанный и тщательно протестированный драйвер поставляется с цифровой подписью (Driver Signing). Правильная настройка системы заключается в запрещении установки драйверов без корректной подписи.
· Модуль управления объектами (Object Manager), управления виртуальной памятью (Virtual Memory Manager), управления процессами (Process Manager), управления безопасностью (Security Reference Monitor), управления локальными вызовами (Local Procedure Calls Facilities) - важные компоненты ядра системы подробно рассматриваться не будут.
Наконец, особое по значению и важности место в ядре системы занимает модуль графического интерфейса - Win32k.sys. Фактически - это часть подсистемы Win32, отвечающая за прорисовку и управление графическим интерфейсом. Этот модуль расположен в ядре специально для того, чтобы существенно повысить производительность графических операций ввода/вывода. Однако размещение столь критической части в ядре накладывает чрезвычайно строгие требования к корректности его исполнения. Фактически, ошибка в коде Win32k.sys приведет к краху системы. Разработчики Windows уделяют огромное внимание этому модулю, и именно он наиболее тщательно протестирован. Опыт эксплуатации систем Windows показывает, что код Win32k.sys работает абсолютно корректно и не содержит фатальных ошибок. Однако некорректный драйвер видеосистемы может все испортить.
В Windows также реализованы дополнительные функции для повышения стабильности работы ОС. Система защиты файлов Windows автоматически предотвращает случайные изменения системных файлов операционной системы, вносимые пользователем или приложениями, эффективно защищая всю систему в целом. То есть, когда какая-то программа внесла изменения или просто заменила системные файлы Windows, считая, что у программы более новые, Windows отслеживает изменения и уведомляет об этом пользователя, говоря, что для стабильности системы желательно восстановить исходные файлы. Так же существует поддержка нескольких версий DLL, что повышает совместимость приложений и повышает стабильность.
Компоненты пользовательского режима
Подсистема пользовательского интерфейса в Windows NT реализует оконный интерфейс, подобный интерфейсу предыдущих версий Windows. Двумя типами объектов этой подсистемы, отсутствовавшими в 16-битных версиях Windows и в Windows 9x, являются оконные станции и рабочие столы. Оконная станция соответствует одному сеансу пользователя Windows NT — например, при подключении через службу удалённого рабочего стола создаётся новая оконная станция. Каждый запущенный процесс принадлежит одной из оконных станций; службы, кроме помеченных как способные взаимодействовать с рабочим столом, запускаются в отдельных, невидимых оконных станциях.
Каждая оконная станция имеет собственный буфер обмена, набор глобальных атомов (используемых для операций DDE), и набор рабочих столов. Рабочий стол является контекстом всех глобальных операций подсистемы пользовательского интерфейса, таких как установка хуков и широковещательная рассылка сообщений. Каждый запущенный поток принадлежит к одному из рабочих столов — тому, где расположены обслуживаемые им окна; в частности, один поток не может создать несколько окон, принадлежащих к различным рабочим столам. Один из рабочих столов может быть активным (видимым пользователю и способным реагировать на его действия), остальные рабочие столы спрятаны. Возможность создать для одного сеанса работы несколько рабочих столов и переключаться между ними до настоящего времени не предоставлялась стандартными средствами пользовательского интерфейса Windows, хотя существуют сторонние программы, дающие доступ к этой функциональности.
Оконными станциями и рабочими столами исчерпываются объекты подсистемы пользовательского интерфейса Windows NT, которым могут быть назначены права доступа. Оставшиеся типы объектов — окна и меню — предоставляют полный доступ любому процессу, который находится с ними в одной оконной станции. Поэтому службы Windows NT по умолчанию запускаются в отдельных оконных станциях: они работают с повышенными привилегиями, и возможность процессов пользователя неограниченно манипулировать окнами служб могла бы привести к сбоям и/или проблемам безопасности.
Win32 API
Чаще всего прикладными программами для Windows NT используется Win32 API — интерфейс, созданный на основе API ОС Windows 3.1, и позволяющий перекомпилировать существующие программы для 16-битных версий Windows с минимальными изменениями исходного кода. Совместимость Win32 API и 16-битного Windows API настолько велика, что 32-битные и 16-битные приложения могут свободно обмениваться сообщениями, работать с окнами друг друга и т. д. Кроме поддержки функций существовавшего Windows API, в Win32 API был также добавлен ряд новых возможностей, в том числе поддержка консольных программ, многопоточности, и объектов синхронизации, таких как мьютексы и семафоры. Документация на Win32 API входит в состав Microsoft Platform SDK (англ.) и доступна на веб-сайте.[5]
Библиотеки поддержки Win32 API в основном названы так же, как системные библиотеки Windows 3.x, с добавлением суффикса 32: это библиотеки kernel32, advapi32, gdi32, user32, comctl32, comdlg32, shell32 и ряд других. Функции Win32 API могут либо самостоятельно реализовывать требуемую функциональность в пользовательском режиме, либо вызывать описанные выше функции Native API, либо обращаться к подсистеме csrss посредством механизма LPC (англ.), либо осуществлять системный вызов в библиотеку win32k, реализующую необходимую для Win32 API поддержку в режиме ядра. Четыре перечисленных варианта могут также комбинироваться в любом сочетании: например, функция Win32 API WriteFile обращается к функции Native API NtWriteFile для записи в дисковый файл, и вызывает соответствующую функцию csrss для вывода в консоль.
Функции библиотек подсистемы окружения Win32 необходимо разделить на две группы. К первой относятся функции, не требующие перехода в режим ядра, т. е. полностью реализованные в соответствующей DLL (GetCurrentProcess). Вторая группа функций - функции, требующие вызова к Ntdll.dll и как следствие переключения в режим ядра (WriteFile).
В режиме ядра также работают USER и GDI (подсистемы, реализующие GUI-интерфейс). Но в отличие от библиотек Kernel32.dll и Advapi32.dll, библиотеки User32.dll и Gdi32.dll транслируют свои вызовы в драйвер режима ядра Win32k.sys, который также является частью подсистемы Win32.
Исполнительная система и ядро
Ntdll.dll является всего лищь DLL-библиотекой пользовательского режима, для обработки API в режиме ядра она обращается к компонентам операционной системы. В Windows 2000 следует различать исполнительную систему (executive), содержащую базовые сервисы операционной системы и ядро (kernel), содержащего низкоуровневые сервисы операционной системы. Если представлять в виде иерархии, то Executive находится выше ядра, т. к. для реализации той или иной API ей требуется обращения к ядру. Например, планирование потоков происходит в диспетчере потоков в Executive, но сама диспетчеризация (переключение контекста) в ядре. Исполнительная система Executive образует верхний уровень Ntoskrnl.exe, а ядро - нижний. Executive состоит из диспетчеров, таких как диспетчер процессов, потоков, ввода-вывода и др.
Диспетчер системных сервисов
За направление на обработку соответствующему диспетчеру соответствующего системного сервиса отвечает диспетчер системных сервисов - функция KiSystemService в Ntoskrnl.exe. Она осуществляет диспетчеризацию или обработку системного сервиса, используя таблицу диспетчеризации системных сервисов. Вызов (активация) диспетчера системных сервисов происходит в результате программного прерывания int 0x2e (на процессорах х86), эта инструкция располагается в каждом сервисе в Ntdll.dll. Следующая схема иллюстрирует обработку системного сервиса.
KiSystemService принимает номер системного сервиса от Ntdll.dll, находит соответствующий элемент в таблице диспетчеризации системных сервисов и передает системный сервис на обработку исполнительной системе. Ntdll.dll передает в регистре EAX номер системного сервиса, регистр EBX указывает на параметры, передаваемые системному сервису. Затем следует инструкция int 0x2e и по таблице диспетчеризации прерываний, управление передается диспетчеру системных сервисов.
Вызываемые интерфейсы ядра
Как уже было указано, соответствующие библиотеки транслируют API-вызовы в вызовы к Ntdll.dll для переключения в режим ядра. Вызываемые функции Ntdll.dll, называются интерфейсами диспетчера системных сервисов или вызываемыми интерфейсами ядра. Microsoft некоим образом не документирует эти функции, а если и можно встретить в Platform SDK какую-то функцию, экспортируемую из Ntdll.dll, то будет указано, что лучше использовать соответствующие функции Win32 API и не лезть в библиотеку системной поддержки.
Для того, чтобы вызвать системный сервис из Ntdll.dll, нужно получить ее адрес в виртуальном адресном пространстве процесса функцией LoadLibrary, а затем получить указатель на соответствующую функцию вызовом GetProcAddress. Например, в следующем коде показано, как вызвать сервис NtQuerySystemInformation из Ntdll.dll для получения информации о количестве процессоров, установленных в системе.
| //Определяем таким образом для Windows XP #define _WIN32_WINNT 0x0501 #include #include #include #define STATUS_SUCCESS (NTSTATUS)0x00000000L void main() { SYSTEM_BASIC_INFORMATION sysinfo; ULONG ReturnLength; NTSTATUS (WINAPI *pNtQuerySystemInformation)(SYSTEM_INFORMATION_CLASS, PVOID,ULONG,PULONG); HMODULE hModule=LoadLibrary("Ntdll.dll"); pNtQuerySystemInformation= (NTSTATUS (WINAPI*)(SYSTEM_INFORMATION_CLASS,PVOID,ULONG,PULONG)) GetProcAddress(hModule,"NtQuerySystemInformation"); if(pNtQuerySystemInformation==NULL) abort(); if(((pNtQuerySystemInformation)(SystemBasicInformation,&sysinfo, sizeof(sysinfo),&ReturnLength))!=STATUS_SUCCESS) abort(); printf("Number of processors: %d\n",sysinfo.NumberOfProcessors); } |
Здесь в качестве примера вызывается внутренний сервис NtQuerySystemInformation в Ntdll.dll. Обратите внимание, что Ntdll.dll не проецируется на виртуальное адресное пространство процесса при вызове LoadLibrary, т. к. она проецируется на начальном этапе запуска процесса. Здесь получается лишь ее базовый адрес в виртуальном адресном пространстве процесса.
Обратите особое внимание на файл winternl.h, в котором объявлены многие недокументированные структуры и функции. Наконец-то Microsoft приоткрыла завесу тайны над внутренними сервисами, экспортируемыми Ntdll.dll.
Этот заголовочный файл стал настоящей находкой для системных программистов, т. к. он содержит объявления многих недокументированных сервисов, экспортируемых из Ntdll.dll. Остается только догадываться, почему Microsoft решилась объявить эти функции, хотя они до сих пор относятся к разряду не документированных. К их числу относят: NtCreateFile, NtOpenFile, NtWaitForSingleObject. Например, прототип всем известного внутреннего сервиса NtCreateFile выглядит следующим образом.
NTSTATUS NtCreateFile(PHANDLE FileHandle, ACCESS_MASK DesiredAccess,
POBJECT_ATTRIBUTES ObjectAttributes, PIO_STATUS_BLOCK IoStatusBlock,
PLARGE_INTEGER AllocationSize, ULONG FileAttributes, ULONG ShareAccess, ULONG CreateDisposition, ULONG CreateOptions, PVOID EaBuffer, ULONG EaLength);
Мало того, в Platform SDK Windows Server 2003 можно встретить описание этих недокументированных функций. Последнюю версию можно скачать с сайта Microsoft.
Функции, экспортируемые Ntdll.dll
Просмотреть вызываемые интерфейсы ядра, можно, используя программу dumpbin с ключом /EXPORTS. Она отобразит все экспортируемые Ntdll.dll функции. Как окажется, Ntdll.dll экспортирует множество разнообразных функций, в том числе, такие функции, как strcmp, strcpy для оперирования ANSI-строками и wcscmp, wcscpy для Unicode-строк.
Большинство функций Ntdll.dll начинаются со следующих префиксов. Сс Диспетчер кэша
· Cm Диспетчер конфигурации
· Ex Функции поддержки Executive
· FsRtl Функции библиотеки периода выполения драйвера файловой системы
· Hal Функции HAL
· Функции диспетчера ввода-вывода
· Ke Функции ядра
· Lpc Механизм Lpc
· Lsa Локальная аутентификация
· Mm Функции диспетчера памяти
· Nt Системные сервисы
· Ob Функии диспетчера объектов
· P- Функции диспетчера электропитания
· Pp Функции диспетчера Plug and Play
· Ps Функции поддержки процессов
· Rtl Функции библиотеки периода выполнения
· Se Функции защиты
· Wmi WMI
· Zw Точка входа для системных сервисов (аналогичная префиксу Nt)
GDI (Graphics Device Interface, Graphical Device Interface) — один из трёх основных компонентов или «подсистем», вместе с ядром и Windows API составляющих пользовательский интерфейс (оконный менеджер GDI) Microsoft Windows.
GDI — это интерфейс Windows для представления графических объектов и передачи их на устройства отображения, такие как мониторы и принтеры.
GDI отвечает за отрисовку линий и кривых, отображение шрифтов и обработку палитры. Он не отвечает за отрисовку окон, меню и т. п., эта задача закреплена за пользовательской подсистемой, располагающейся в user32.dll и основывающейся на GDI. GDI выполняет те же функции, что и QuickDraw в Mac OS.
Одно из преимуществ использования GDI вместо прямого доступа к оборудованию — это унификация работы с различными устройствами. Используя GDI, можно одними и теми же функциями рисовать на разных устройствах, таких как экран или принтер, получая на них практически одинаковые изображения. Эта возможность лежит в центре всех WYSIWYG-приложений для Windows.
Простые игры, которые не требуют быстрой графики, могут использовать GDI. Однако GDI не обеспечивает качественной анимации, поскольку в нём нет возможности синхронизации с кадровым буфером. Также, в GDI нет растеризации для отрисовки 3D-графики. Современные игры используют DirectX или OpenGL, что даёт программистам доступ к большему количеству аппаратных возможностей.
Для определения атрибутов текста и изображения, которые выводятся на экран или принтер, используется программный объект под названием «контекст устройства» (Device Context, DC). DC, как и большинство объектов GDI, инкапсулирует подробности реализации и данные в себе и к ним нельзя получить прямой доступ.
Для любого рисования нужен объект HDC (хэндл DC). При выводе на принтер HDC получается вызовом CreateDC, и на нем зовутся специальные функции для перехода на новую страницу печатаемого документа. При выводе на экран также можно использовать CreateDC, но это приведет к рисованию поверх всех окон вне их границ, потому обычно для рисования на экране используются вызовы GetDC и BeginPaint, принадлежащие уже не GDI, а USER, и возвращающие контекст, ссылающийся на регион отсечения окна.
Функционал:
· вывод одними и теми же вызовами на экран, принтер, «экран в памяти» (доступный приложению по указателю и созданный им bitmap в памяти, также возможно выделение bitmapов в памяти видеокарты — CreateCompatibleBitmap — и рисование на них, такие битовые карты не доступны по указателю, но дальнейшая перерисовка с них на физический экран происходит очень быстро без нагрузки процессора и шины, и особенно быстро в случае Remote Desktop).
· вывод в метафайл — запоминание последовательности команд рисования в файле, можно проиграть заново, векторный графический файл.wmf есть именно этот метафайл с небольшим дополнительным заголовком в начале.
· вывод текста различными шрифтами, в т. ч. TrueType и OpenType, а также шрифтами, вшитыми в принтер (при изображении документа на экране используется ближайший похожий программно реализованный шрифт). Буквы всегда заливаются одним цветом («текущий цвет»), промежутки между ними либо остаются прозрачными, либо же заливаются другим цветом («текущий цвет фона»). Не поддерживается расположение букв по кривой.
· богатый набор операций с bitmapами, включая масштабирование, автоматическое преобразование из стандартных форматов в текущий формат экрана без усилий со стороны программиста (StretchDIBits), рисование на bitmapах нескольких стандартных форматов, находящихся в памяти, и огромное количество логических операций комбинирования цветов 2 bitmapов — уже имеющегося на устройстве назначения и вновь рисуемого.
· богатый набор операций векторной графики (примерно тот же, что в PostScript, но используется другой вид сплайнов). Проводимая линия имеет атрибуты — толщину, рисунок пунктира и цвет (собраны вместе в т. н. объекте PEN) и способ сглаживания углов многоугольников. Заливка может быть одноцветной, одной из стандартных штриховок или же bitmapом 8 на 8 (эти атрибуты собраны в «объекте BRUSH»). В Windows NT также появились сплайны Безье.
· все цвета в вызовах — всегда в RGB, независимо от системы цветов текущего устройства. Исключение — отдельные пикселы внутри bitmapов, которые могут быть и в виде, определенном устройством.
· поддержка регионов отсечения и всех основных логических операций над ними. Координаты в них — 16-битные целые (что ограничивало размер экрана Windows, даже довольно поздних версий, до 32K пикселов).
· поддержка матрицы поворотов/растяжений — World Transform, не поддерживается для регионов отсечения, только для векторной графики.
В Windows 9x и более ранних реализована в 16-битной GDI.DLL, которая в свою очередь подгружает выполненный в виде DLL драйвер видеокарты. Драйвер видеокарты первоначально и был обязан реализовать вообще все рисование, в т. ч. рисование на bitmapах в памяти в формате экрана. Позже появилась DIBENG.DLL, в которой было реализовано рисование на bitmapах стандартных форматов, драйвер был обязан пропускать в нее все вызовы, кроме тех, для которых он задействовал аппаратный ускоритель видеокарты.
Драйвер принтера подгружался таким же образом и имел тот же интерфейс «сверху», но «снизу» он вместо рисования в памяти/на аппаратуре генерировал последовательности команд принтера и отсылал их в объект Job. Эти команды как правило были либо бинарные и не читаемые человеком, либо PostScript.
В Windows NT GDI была полностью переписана с нуля заново, причем на Си++ (по слухам, у Microsoft тогда не было компилятора этого языка и они использовали cfront). API для приложений не изменился (кроме добавления кривых Безье), для драйверов — обертки на языке Си вокруг реализованных на Си++ внутренностей (вроде BRUSHOBJ_pvGetRbrush).
Сама GDI была размещена сначала в WINSRV.DLL в процессе CSRSS.EXE, начиная с NT4 — в win32k.sys. Драйверы загружались туда же. DIBENG.DLL была переписана заново и перенесена туда же как совокупность вызовов EngXxx - EngTextOut и другие. Логика взаимодействия драйвера-GDI-DIBENG осталась примерно та же.
GDI32.DLL в режиме пользователя реализована как набор специальных системных вызовов, ведущих в win32k.sys (до NT4 — как обертки вокруг вызова CsrClientCallServer, посылавшего сообщение в CSRSS.EXE).
В Windows Vista появилась модель драйверов WDDM, в которой была отменена возможность использования аппаратуры двухмерной графики. При использовании WDDM все GDI-приложения (т. е. все обычные системные части Windows UI — заголовки и рамки окон, рабочий стол, таскбар и другое) используют GDI-драйвер cdd.dll (Canonical Display Driver), который рисует на некоторых bitmapах в памяти, своих для каждого окна (содержимое окна стало запоминаться в памяти, до того Windows никогда так не делала и всегда перерисовывала окна заново, кроме неких специальных окон с флагом CS_SAVEBITS). Изображения из cdd.dll извлекаются процессом dwm.exe (Desktop Window Manager), который является Direct3D-приложением и отрисовывает «картинки окон» на физическом экране через Direct3D.
Сам же WDDM-драйвер поддерживает только DirectDraw и Direct3D и не имеет отношения ни к GDI, ни к win32k.sys, сопрягаясь с модулем dxgkrnl.sys в ядре.
User mode и kernel mode
При обсуждении архитектуры ОС Windows NT постоянно используются понятия «режим пользователя» и «режим ядра», поэтому стоит определить, что это значит. Начнем с обсуждения разницы между пользовательским режимом и режимом ядра (user mode/kernel mode).
Пользовательский режим - наименее привилегированный режим, поддерживаемый NT; он не имеет прямого доступа к оборудованию и у него ограниченный доступ к памяти.
Режим ядра - привилегированный режим. Те части NT, которые исполняются в режиме ядра, такие как драйверы устройств и подсистемы типа Диспетчера Виртуальной Памяти, имеют прямой доступ ко всей аппаратуре и памяти.
Различия в работе программ пользовательского режима и режима ядра поддерживаются аппаратными средствами компьютера (а именно - процессором).
Большинство архитектур процессоров обеспечивают, по крайней мере, два аппаратных уровня привилегий. Аппаратный уровень привилегий процессора определяет возможное множество инструкций, которые может вызывать исполняемый в данный момент процессором код. Хотя понятия «режим пользователя» и «режим ядра» часто используются для описания кода, на самом деле это уровни привилегий, ассоциированные с процессором. Уровень привилегий накладывает три типа ограничений:
1) возможность выполнения привилегированных команд,
2) запрет обращения к данным с более высоким уровнем привилегий,
3) запрет передачи управления коду с уровнем привилегий, не равным уровню привилегий вызывающего кода.
24. Системный реестр (структура системного реестра Windows).
Редактор системного реестра. Импорт и экспорт данных системного реестра.
Предопределенные ключи системного реестра.
Создание резервных копий и восстановление системного реестра.
Регистрация типа документа и расширения имени файла в реестре (Лаб.раб 3).
Реестр Windows XP отличается многоуровневой архитектурой, включающей в себя четыре нисходящих логических компонента. К первому компоненту, расположенному в самом верху иерархии реестра, относятся так называемые ветви реестра. Эти ветви обозначаются с использованием англоязычной аббревиатуры HKEY_. После символа подчеркивания идет название самой ветви. Всего в реестре Windows XP есть пять основных ветвей: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS и HKEY_CURRENT_CONFIG.
К второму компоненту в системе иерархии реестра относятся разделы, или ключи реестра (keys). В Windows XP не существует универсального стандарта для обозначения ключей реестра, поэтому имена для них назначались разработчиками согласно типам данных, которые расположены в ключе. Работать с ключами можно в программе Редактор реестра (RegEdit), где они отображаются в виде подпапок ветвей HKEY_, как показано рисунке ниже.
Строго говоря, ограничений, которые соотносят с ключами конкретный тип данных, попросту не существует. Поэтому ключи в архитектуре реестра используются лишь для того, чтобы упростить доступ к информации и предоставляют собой, фактически, просто средством для упорядочивания больших массивов данных реестра.
По своему функциональному предназначению ключи реестра разделяются на две следующие категории.
· Указываются системой. Имена ключей выбираются ОС, их изменение может сделать Windows XP полностью неработоспособной.
· Указываются пользователем. Имена ключей может изменять администратор компьютера, и такие модификации не станут причиной каких-либо фатальных проблем.
Ступенькой ниже в структурной иерархии реестра расположены подразделы реестра (subkeys). Подразделы также прямо не связаны с какими-либо типами данных и не используются в рамках каких-либо соглашений, которые ограничивают присвоение им названий. Наравне с именами ключей, названия подразделов определяются как ОС, так и пользователем, причем в первом случае их модификация может стать причиной проблем в работе Windows, а во втором — нет.
Финальная ступень в архитектуре системного реестра называется параметром (values). Это компонент реестра, содержащий непосредственно сами данные, которые обуславливают работу ОС и всего компьютера. Параметры, фактически, являются цепочкой «имя параметра — значение параметра» и различаются по типу содержащейся в качестве их значений информации.
Теперь попробуем посмотреть на архитектуру реестра под другим углом, и сравним ее с файловой системой компьютера. В этой аналогии ветви будут выполнять ту же роль, что и корневые папки разделов жесткого диска, ключи и подразделы станут папками и подпапками, а параметры — непосредственно файлами, которые находятся в своих папках. При этом любой из подобных файлов может иметь название (имя параметра) и расположенную в нем информацию (значение параметра).
Разобравшись с реестром, перейдем к обзору типы данных, которые хранятся в параметрах реестра Windows.
Типы данных системного реестра Windows
Для классификации значений, расположенных в параметрах, используются типы данных, связанные с этим значением. Существует ровным счетом 11 типов данных системного реестра, перечисленных далее.
· REG_NONE. Тип данных «Неизвестный». Зашифрованные данные.
· REGSZ. Тип данных «Строковый». Текст.
· REG_EXPAND_SZ. Тип данных «Строковый». Текст и переменные.
· REG_BINARY. Тип данных «Двоичный». Двоичные данные.
· REG_DWORD. Тип данных «Числовой». Число.
· REG_DWORD_BIN_ENDIAN. Тип данных «Числовой». Число с обратным порядком байтов.
· REG_LINK. Тип данных «Строковый». Путь к файлу.
· REG_MULTI_SZ. Тип данных «Многостроковый». Массив строк.
· REG_RESOURCE_LIST. Тип данных «Строковый». Список ресурсов устройств.
· REG_FULL_RESOURCE_DESCRIPTOR. Тип данных «Строковый». Идентификатор ресурса устройства.
· REG_RESOURCE_REQUIREMENTS_LIST. Тип данных «Строковый». Идентификатор ресурса устройства.
Любой пользователь может свободно редактировать все значения параметров реестра, причем не важно, к какому типу данных, из указанных ранее, они относятся. В программе Редактор реестра представлен набор встроенных мастеров, которые дают возможность менять разнообразные типы данных. В частности, для настройки значений числовых параметров используется мастер DWORD, двоичных — BINARY, строковых — STRING и многостроковых — MULTISTRING.
Теперь перейдем к рассмотрению пяти базовых ветвей системного реестра Windows XP, и расскажем об их функциональном предназначении. (Предопределенные ключи системного реестра)
· HKEY_LOCAL_MACHINE (HKLM). В этой ветви представлены данные, связанные с