Внутри собственных приложений
Марк Руссинович опубликован: 1 ноября 2006 г.
Введение
Если у вас есть некоторые знания об архитектуре NT, вероятно, известно, что API, используемый приложениями Win32, не является реальным API NT. Операционные среды NT, в том числе POSIX, OS/2 и Win32, разговаривают с клиентскими приложениями через собственные API, но разговаривают с NT с помощью СОБСТВЕННОго API NT. Собственный API в основном недокументирован, только около 25 из его 250 функций, описанных в комплекте драйверов устройств Windows NT.
Однако большинство людей не знают, что "собственные" приложения существуют в NT, которые не являются клиентами любой из операционных сред. Эти программы говорят об собственном API NT и не могут использовать API операционной среды, такие как Win32. Почему такие программы должны быть необходимы" Любая программа, которая должна выполняться до запуска подсистемы Win32 (примерно во время появления поля входа) должна быть собственным приложением. Наиболее видимым примером собственного приложения является программа autochk, которая запускает chkdsk во время инициализации Синего экрана (это программа, которая печатает "." s на экране). Естественно, сервер операционной среды Win32, CSRSS.EXE (подсистема среды выполнения клиента-сервера), также должен быть собственным приложением.
В этой статье мы рассмотрим, как создаются собственные приложения и как они работают.
Как выполняется автоматическое выполнение
Автоматическое заполнение выполняется между загрузкой NT и драйверами запуска системы, а также при включении разбиения по страницам. На этом этапе диспетчер сеансов последовательности загрузки (smss.exe) получает среду пользовательского режима NT вне земли, и другие программы не активны. Значение HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute , MULTI_SZ, содержит имена и аргументы программ, выполняемых диспетчером сеансов, и указывает, где указан авточек. Вот что обычно можно найти при просмотре этого значения, где "Autochk" передается "*" в качестве аргумента:
Autocheck Autochk *
Диспетчер сеансов выглядит в каталоге <winnt>\system32 для исполняемых файлов, перечисленных в этом значении. При запуске Autochk нет файлов, поэтому Autochk может открывать любой том в необработанном режиме, включая загрузочный диск, и управлять структурами данных на диске. Это было бы невозможно в любой другой момент.
Создание собственных приложений
Корпорация Майкрософт не документирует его, но программа сборки NT DDK знает, как создавать собственные приложения (и, вероятно, используется для компиляции Autochk). Вы указываете сведения в файле SOURCES, который определяет приложение, то же самое, что и для драйверов устройств. Однако вместо указания на сборку, которую требуется драйвер, вы сообщите ему, что в файле SOURCES нужно создать собственное приложение, как показано ниже:
TARGETTYPE=PROGRAM
Служебная программа сборки использует стандартный файл makefile для его руководства , \ddk\inc\makefile.def, которая ищет библиотеку времени выполнения с именем nt.lib при компиляции собственных приложений. К сожалению, корпорация Майкрософт не отправляет этот файл с DDK (его входит в DDK Server 2003, но я подозреваю, что если вы связываетесь с этой версией собственного приложения не будет работать в XP или Windows 2000). Однако эту проблему можно обойти, включив строку в makefile.def, переопределяющую выбор nt.lib, указав библиотеку среды выполнения Visual C++, msvcrt.lib
Если вы запускаете сборку в среде DDK "Проверенная сборка", она создаст собственное приложение с полной отладочной информацией в папке %BASEDIR%\lib%CPU%\Checked (например, c:\ddk\lib\i386\проверка ed\native.exe), и если вызвать ее в среде "Бесплатная сборка", версия выпуска программы завершится в %BASEDIR%\lib%CPU%\Free. Это те же места, где образы драйверов устройств помещаются сборкой.
Собственные приложения имеют расширения файлов .exe, но их нельзя запускать, как .exe Win32. Если вы попытаетесь получить сообщение:
Приложение нельзя запустить в режиме Windows NT.
Внутри собственного приложения
Вместо winmain или main точка входа для собственных приложений — NtProcessStartup. Кроме того, в отличие от других точек входа Win32, собственные приложения должны обращаться к структуре данных, передаваемой в качестве единственного параметра, чтобы найти аргументы командной строки.
Большинство среды выполнения собственного приложения предоставляется NTDLL.DLL собственной библиотекой экспорта API NT. Собственные приложения должны создавать собственную кучу, из которой следует выделить хранилище с помощью RtlCreateHeap, функции NTDLL. Память выделяется из кучи с RtlAllocateHeap и освобождается с помощью RtlFreeHeap. Если собственное приложение хочет распечатать что-то на экране, оно должно использовать функцию NtDisplayString, которая будет выводить на синий экран инициализации.
Собственные приложения не просто возвращаются из своей функции запуска, например программы Win32, так как код среды выполнения не возвращается. Вместо этого они должны завершиться путем вызова NtProcessTerminate.
Среда выполнения NTDLL состоит из сотен функций, позволяющих собственным приложениям выполнять операции ввода-вывода файлов, взаимодействовать с драйверами устройств и выполнять межпроцессное взаимодействие. К сожалению, как я уже говорил ранее, подавляющее большинство этих функций являются незадокументированы.