Dentro de aplicaciones nativas

Mark Russinovich publicado: 1 de noviembre de 2006

Introduction

Si tiene cierta familiaridad con la arquitectura de NT, probablemente tenga en cuenta que la API que usan las aplicaciones Win32 no es la API NT "real". Los entornos operativos de NT, que incluyen POSIX, OS/2 y Win32, hablan con sus aplicaciones cliente a través de sus propias API, pero hablen con NT mediante la API "nativa" de NT. La API nativa es principalmente no documentada, con solo 25 de sus 250 funciones descritas en el kit de controladores de dispositivos NT de Windows.

Sin embargo, lo que la mayoría de las personas no saben es que existen aplicaciones "nativas" en NT que no son clientes de ninguno de los entornos operativos. Estos programas utilizan la API NT nativa y no pueden usar API del entorno operativo como Win32. ¿Por qué se necesitan estos programas"Cualquier programa que se debe ejecutar antes de que se inicie el subsistema Win32 (alrededor del momento en que aparece el cuadro de inicio de sesión) debe ser una aplicación nativa. El ejemplo más visible de una aplicación nativa es el programa "autochk", que ejecuta chkdsk durante la pantalla azul de inicialización (es el programa que muestra los puntos «.» en la pantalla). Naturalmente, el servidor de entorno operativo Win32, CSRSS.EXE (Client-Server Subsistema en tiempo de ejecución), también debe ser una aplicación nativa.

En este artículo describiré cómo se compilan las aplicaciones nativas y cómo funcionan.

Cómo se ejecuta Autochk

Autochk se ejecuta entre el momento en que se cargan los controladores de arranque y de inicio del sistema de NT y cuando se activa la paginación. En este punto de la secuencia de arranque, el Administrador de sesiones (smss.exe) está poniendo en marcha el entorno en modo de usuario de NT y no hay ningún otro programa activo. El valor HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute , un MULTI_SZ, contiene los nombres y argumentos de los programas que ejecuta el Administrador de sesiones y es donde se especifica Autochk. Esto es lo que normalmente se encuentra al examinar este valor, cuando se le pasa "*" como argumento a "Autochk":

Autocheck Autochk *

El Administrador de sesiones busca en el <directorio winnt>\system32 los ejecutables enumerados en este valor. Cuando Autochk se ejecuta no hay archivos abiertos, por lo que Autochk puede abrir cualquier volumen en modo sin procesar, incluida la unidad de arranque, y manipular sus estructuras de datos en disco. Esto no sería posible en ningún momento posterior.

Creación de aplicaciones nativas

Microsoft no lo documenta, pero la utilidad de compilación de NT DDK sabe cómo crear aplicaciones nativas (y es probable que se use para compilar Autochk). Especifique información en un archivo SOURCES que defina la aplicación, igual que lo haría para los controladores de dispositivo. Sin embargo, en lugar de indicarle a Build que desea un controlador, se le indica que desea una aplicación nativa en el archivo SOURCES de la siguiente manera:

TARGETTYPE=PROGRAM

La utilidad Build usa un archivo make estándar para guiarlo, \ddk\inc\makefile.def, que busca una biblioteca en tiempo de ejecución denominada nt.lib al compilar aplicaciones nativas. Desafortunadamente, Microsoft no envía este archivo con el DDK (incluido en el DDK server 2003, pero sospecho que si vincula con esa versión la aplicación nativa no se ejecutará en XP o Windows 2000). Sin embargo, puede solucionar este problema si incluye una línea en makefile.def que invalida la selección de nt.lib especificando la biblioteca en tiempo de ejecución de Visual C++, msvcrt.lib

Si ejecuta Build en el entorno "Checked Build" de DDK, generará una aplicación nativa con información de depuración completa en %BASEDIR%\lib%CPU%\Checked (por ejemplo, c:\ddk\lib\i386\checked\native.exe), y si lo invoca en el entorno "Compilación gratuita", una versión de lanzamiento del programa terminará en %BASEDIR%\lib%CPU%\Free. Estas son las mismas ubicaciones en las que build coloca las imágenes del controlador de dispositivo.

Las aplicaciones nativas tienen extensiones de archivo ".exe", pero no se pueden ejecutar como Win32 .exe' s. Si lo intentas, recibirás el mensaje:

La aplicación no se puede ejecutar en Windows modo NT.

Dentro de una aplicación nativa

En lugar de winmain o main, el punto de entrada para las aplicaciones nativas es NtProcessStartup. A diferencia de los otros puntos de entrada de Win32, las aplicaciones nativas deben acceder a una estructura de datos que se les pasa como único parámetro para encontrar los argumentos de la línea de comandos.

La mayoría del entorno de tiempo de ejecución de una aplicación nativa se proporciona mediante NTDLL.DLL, la biblioteca de exportación de API nativa de NT. Las aplicaciones nativas deben crear su propio montón desde el que asignar almacenamiento mediante RtlCreateHeap, una función NTDLL. La memoria se asigna desde un montón con RtlAllocateHeap y se libera con RtlFreeHeap. Si una aplicación nativa desea imprimir algo en la pantalla, debe usar la función NtDisplayString, que se generará en la pantalla azul de inicialización.

Las aplicaciones nativas no se limitan a salir de su función de inicio como los programas Win32, ya que no hay código de tiempo de ejecución al que regresar. En su lugar, deben finalizar por sí mismos mediante una llamada a NtProcessTerminate.

El entorno de ejecución NTDLL consta de cientos de funciones que permiten a las aplicaciones nativas realizar E/S de archivos, interactuar con controladores de dispositivo y realizar comunicaciones entre procesos. Desafortunadamente, como dije anteriormente, la gran mayoría de estas funciones no están documentadas.