Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
2006 г.

Реализация Win32 API в Windows 2000

Baranov Artem

Введение
Сегодня, наверное, уже не осталось человека, который бы не программировал под Windows с прямым использованием ее API-функций, а не функций библиотеки компиляторов. Действительно, Windows 2000 предлагает столь внушительный набор экспортирумых функций, что их с избытком хватит для решения широкого круга задач. Другое преимущество заключается в том, что вызов API-функций позволяет взаимодействовать с Windows напрямую, минуя стандартные библиотеки компилятора. Но возникают несколько вопросов, например, откуда экспортируются функции API и как они реализованы. Данная статья поможет пролить свет на данные вопросы.
Подсистемы окружения
Наверное, первое что интересует программиста, который начинает писать программы с использованием Win32 API, так это то, откуда они экспортируются. Win32 API экспортируется из четырех динамически подключаемых библиотек: Kernel32.dll, User32.dll, Gdi32.dll, Advapi32.dll (Advanced API). Сразу нужно определиться с тем, что Windows 2000 поддерживает также стандарт на вызовы UNIX - POSIX, которые также реализованы в Windows 2000. Поэтому для Windows 2000 определено такое понятие, как подсистема окружения (subsystem environment) - это часть поддержки среды операционной системы, предоставляемой пользователям и программистам. В Windows 2000 реализовано две подсистемы окружения: Win32 и POSIX. Первая является "родной" подсистемой, без которой работа Windows 2000 не представляется возможной, вторая запускается по требованию и предназначена для поддержки UNIX-приложений. Каждый EXE-файл принадлежит только одной подсистеме окружения и может вызывать только API, реализованные этой подсистемой. Таким образом, каждая подсистема проецирует на приложение свой образ операционной системы.
Ntdll.dll
Отличительной чертой Windows является то, что интерфейсы API отделены от их реализации. Это позволяет Microsoft изменять от версии к версии внутренние функции Windows, но оставлять неизменными функции в интерфейсных библиотеках. Так как для обработки большинства API-функций необходимо переключиться в режим ядра, то должна существовать универсальная библиотека, работающая как шлюз между пользовательским режимом и режимом ядра. Такой библиотекой является Ntdll.dll. Для каждой функции в Ntdll.dll существует инструкция перехода в привилегированный режим работы процессора для обработки соответствующей API-функции.

Функции библиотек подсистемы окружения 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
Io Функции диспетчера ввода-вывода
Ke Функции ядра
Lpc Механизм Lpc
Lsa Локальная аутентификация
Mm Функции диспетчера памяти
Nt Системные сервисы
Ob Функии диспетчера объектов
Po Функции диспетчера электропитания
Pp Функции диспетчера Plug and Play
Ps Функции поддержки процессов
Rtl Функции библиотеки периода выполнения
Se Функции защиты
Wmi WMI
Zw Точка входа для системных сервисов (аналогичная префиксу Nt)

Win32 API и Windows API
С появлением 64-разрядных версий Windows XP и Windows Server 2003, интерфейс программирования в Windows стал называться Windows API, для обозначения как 32-разрядного API, так и 64-разрядного.

Новости мира IT:

Архив новостей

Последние комментарии:

Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...