Dentro de aplicaciones nativas

Mark Russinvl Publicado: 1 de noviembre de 2006

Introducción

Si está familiarizado con la arquitectura de NT, probablemente sea consciente de 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, se hablan con sus aplicaciones cliente a través de sus propias API, pero se hablan con NT mediante la API "nativa" de NT. La API nativa está principalmente sin documentar, con solo unas 25 de sus 250 funciones descritas en el kit de controladores de Windows NT.

Sin embargo, lo que la mayoría de las personas no sabe es que existen aplicaciones "nativas" en NT que no son clientes de ninguno de los entornos operativos. Estos programas hablan la API nativa de NT y no pueden usar API de entorno operativo como Win32. ¿Por qué se necesitan estos programas?: Cualquier programa que se deba ejecutar antes de que se inicie el subsistema Win32 (aproximadamente en el 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 inicialización de la pantalla azul (es el programa que imprime "."" s en la pantalla). Naturalmente, el servidor de entorno operativo Win32, CSRSS.EXE (Subsistema de tiempo de ejecución cliente-servidor), también debe ser una aplicación nativa.

En este artículo describiré cómo se construyen 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á obteniendo el entorno en modo de usuario de NT fuera de servicio y ningún otro programa está 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 encontrará si observa este valor, donde "Autochk" se pasa "*" como argumento:

Autocheck Autochk *

El Administrador de sesiones busca en el directorio winnt > \system32 los ejecutables enumerados en este valor. Cuando se ejecuta Autochk, no hay ningún archivo abierto, 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.

Compilar aplicaciones nativas

Microsoft no lo documenta, pero la utilidad NT DDK Build sabe cómo crear aplicaciones nativas (y probablemente se usa para compilar Autochk). Puede especificar información en un archivo SOURCES que define la aplicación, lo mismo que se haría para los controladores de dispositivo. Sin embargo, en lugar de indicar a Build que quiere un controlador, le indica que quiere una aplicación nativa en el archivo SOURCES de la siguiente forma:

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 de 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 Compilación en el entorno "Compilación activada" del DDK, se producirá 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 la invoca en el entorno de "Compilación gratuita", una versión de lanzamiento del programa terminará en %BASEDIR%\lib%CPU%\Free. Estos son los mismos lugares donde build coloca las imágenes del controlador de dispositivo.

Las aplicaciones nativas tienen extensiones .exe de archivo ,pero no se pueden ejecutar como win32 .exe. Si lo intenta, verá el mensaje:

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

Dentro de una aplicación nativa

En lugar de winmain omain,el punto de entrada para las aplicaciones nativas es NtProcessStartup. Además, a diferencia de los otros puntos de entrada de Win32, las aplicaciones nativas deben acceder a una estructura de datos pasada como su único parámetro para buscar argumentos de 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 nativa de exportación de API 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 mostrará en la pantalla azul de inicialización.

Las aplicaciones nativas no simplemente vuelven de su función de inicio, como los programas Win32, ya que no hay código en tiempo de ejecución al que volver. En su lugar, deben terminar por sí mismos llamando a NtProcessTerminate.

El tiempo 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 he indicado anteriormente, la gran mayoría de estas funciones no están documentadas.