Aplicações Nativas

Mark Russinovich Publicado: 1 de novembro de 2006

Introdução

Se você tem alguma familiaridade com a arquitetura NT você provavelmente está ciente que a API que as aplicações Win32 usam não é a API NT "real". Os ambientes operacionais da NT, que incluem POSIX, OS/2 e Win32, falam com as suas aplicações de clientes através das suas próprias APIs, mas falam com a NT usando a API "nativa" nt. A API nativa é na sua maioria indocumentada, com apenas cerca de 25 das suas 250 funções descritas no kit de controlador de dispositivos NT Windows.

O que a maioria das pessoas não sabe, no entanto, é que aplicações "nativas" existem em NT que não são clientes de nenhum dos ambientes operacionais. Estes programas falam a API nativa nt e não podem usar APIs de ambiente operacional como o Win32. Porque é que esses programas seriam necessários" Qualquer programa que tenha de ser executado antes do início do subsistema Win32 (por volta da hora em que a caixa de início de sposição aparece) deve ser uma aplicação nativa. O exemplo mais visível de uma aplicação nativa é o programa "autochk" que executa o chkdsk durante a inicialização do Blue Screen (é o programa que imprime o "". s no ecrã). Naturalmente, o servidor de ambiente operativo Win32, CSRSS.EXE (Subsistema de Tempo de Execução do Servidor cliente-Servidor), também deve ser uma aplicação nativa.

Neste artigo vou descrever como as aplicações nativas são construídas e como funcionam.

Como é que o Autóctico é executado

O Autochk funciona entre o tempo em que os controladores de arranque e sistema da NT estão carregados e quando a paging é ligada. Neste ponto da sequência de arranque, o Session Manager (smss.exe) está a tirar o ambiente de modo de utilizador da NT fora do solo e nenhum outro programa está ativo. O valor HKLM\System\CurrentControlSet\Control\Control\Session Manager\BootExecute, um MULTI_SZ, contém os nomes e argumentos dos programas que são executados pelo Session Manager, e é onde o Autochk é especificado. Aqui está o que você normalmente vai encontrar se você olhar para este valor, onde "Autochk" é passado "*" como um argumento:

Autocheck Autochk *

Session Manager olha para o > diretório winnt \system32 para os executáveis listados neste valor. Quando o Autochk executa não há ficheiros abertos para que o Autochk possa abrir qualquer volume em modo cru, incluindo a unidade de arranque, e manipular as suas estruturas de dados no disco. Isto não seria possível mais tarde.

Construção de Aplicações Nativas

A Microsoft não documenta, mas o utilitário NT DDK Build sabe como fazer aplicações nativas (e provavelmente usada para compilar o Autochk). Especifica informações num ficheiro SOURCES que define a aplicação, o mesmo que seria feito para os controladores de dispositivos. No entanto, em vez de indicar à Build que quer um motorista, diga-lhe que quer uma aplicação nativa no ficheiro SOURCES como este:

TARGETTYPE=PROGRAM

O utilitário Build utiliza um ficheiro de padrão para guiá-lo, \ddk\inc\makefile.def, que procura uma biblioteca de tempo de execução chamada nt.lib ao compilar aplicações nativas. Infelizmente, a Microsoft não envia este ficheiro com o DDK (o que está incluído no DDK do Servidor 2003, mas suspeito que se ligar a essa versão a sua aplicação nativa não será executada em XP ou Windows 2000). No entanto, pode contornar este problema, incluindo uma linha em makefile.def que substitui a seleção de nt.lib especificando a biblioteca de tempo de execução da Visual C++, msvcrt.lib

Se executar a Build sob o ambiente "Construção Verificada" do DDK, produzirá uma aplicação nativa com informação completa de depuração em %BASEDIR%\lib%CPU%\Checked (por exemplo, c:\ddk\lib\i386\checked\native.exe), e se a invocar no ambiente "Construção Livre", uma versão de lançamento do programa acabará em %BASEDIR%\lib%CPU%\Free. Estes são os mesmos locais onde as imagens do condutor do dispositivo são colocadas pela Build.

As aplicações nativas têm extensões de ficheiros ".exe", mas não é possível executá-las como as .exe win32. Se tentar, receberá a mensagem:

A aplicação não pode ser executada no modo NT Windows.

Dentro de uma aplicação nativa

Em vez de winmain ou principal,o ponto de entrada para aplicações nativas é NtProcessStartup. Também ao contrário dos outros pontos de entrada win32, as aplicações nativas devem chegar a uma estrutura de dados passada como o seu único parâmetro para localizar os argumentos da linha de comando.

A maior parte do ambiente de funcionamento de uma aplicação nativa é fornecida pela NTDLL.DLL, a biblioteca de exportação nativa da API da NT. As aplicações nativas devem criar a sua própria pilha a partir da qual alocar o armazenamento utilizando o RtlCreateHeap,uma função NTDLL. A memória é alocada de um monte com RtlAllocateHeap e libertada com RtlFreeHeap. Se uma aplicação nativa pretender imprimir algo no ecrã, deve utilizar a função NtDisplayString, que irá ser publicada na inicialização do Blue Screen.

As aplicações nativas não regressam simplesmente da sua função de arranque como os programas Win32, uma vez que não há um código de tempo de retorno. Em vez disso, devem terminar-se chamando NtProcessTerminate.

O tempo de execução da NTDLL consiste em centenas de funções que permitem que as aplicações nativas executem o ficheiro I/O, interajam com os controladores do dispositivo e executem comunicações interprocessas. Infelizmente, como já disse anteriormente, a grande maioria destas funções não está documentada.