Adentro de las aplicaciones nativas
Mark Russinovich, publicado el 1 de noviembre de 2006
Introducción
Si tiene cierta familiaridad con la arquitectura de NT, probablemente tiene 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 con NT hablan mediante la API "nativa" de NT. La API nativa está mayormente sin documentar, con solo, aproximadamente, 25 de sus 250 funciones descritas en el Kit de controladores de dispositivos Windows NT.
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 hablan con la API NT nativa y no pueden usar API de entorno operativo como Win32. ¿Por qué se necesitarían 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 evidente de una aplicación nativa es el programa "autochk" que ejecuta chkdsk durante el pantallazo azul de inicio (es el programa que imprime el archivo "."' s en la pantalla). Naturalmente, el servidor de entorno operativo Win32, CSRSS.EXE (Subsistema de tiempo de ejecución de cliente-servidor), también debe ser una aplicación nativa.
En este artículo voy a describir cómo se crean 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 momento, en secuencia de arranque el Administrador de sesiones (smss.exe) está iniciando el entorno en modo de usuario de NT fuera del suelo 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 ingresa "*" como argumento:
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 creación de NT DDK sabe cómo crear aplicaciones nativas (y es, probablemente, usada para compilar Autochk). Especifique información en un archivo SOURCES que defina la aplicación, de la misma forma que se haría para los controladores de dispositivo. Sin embargo, en lugar de indicarle a Build que desea un controlador, le dice 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 guiarla, \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 (está 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 "Compilación comprobada" 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 de controladores de dispositivos.
Las aplicaciones nativas tienen extensiones de archivo ".exe", pero no se pueden ejecutar como Win32 .exe. Si lo intenta obtendrá el mensaje:
La aplicación no se puede ejecutar en modo Windows NT.
Dentro de una aplicación nativa
En lugar de winmain o main, 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 alcanzar una estructura de datos ingresada como su único parámetro para encontrar 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 de exportación de API nativa de NT. Las aplicaciones nativas deben crear su propio montón desde el cual 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 lo generará en la pantalla azul de inicialización.
Las aplicaciones nativas no retornan, simplemente, desde su función de inicio como los programas Win32, ya que no hay ningún código en tiempo de ejecución al cual volver. En su lugar, deben terminarse llamando 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.