Por dentro de aplicativos nativos

Mark Russinovich Publicado em: 1 de novembro de 2006

Introdução

Se você tem alguma familiaridade com a arquitetura do NT, provavelmente está ciente de que a API que os aplicativos Win32 usam não é a API NT "real". Os ambientes operacionais da NT, que incluem POSIX, OS/2 e Win32, conversam com seus aplicativos clientes por meio de suas próprias APIs, mas conversam com a NT usando a API "nativa" do NT. A API nativa é principalmente não documentada, com apenas cerca de 25 de suas 250 funções descritas no Windows NT Device Driver Kit.

O que a maioria das pessoas não sabe, no entanto, é que existem aplicativos "nativos" no NT que não são clientes de nenhum dos ambientes operacionais. Esses programas falam a API NT nativa e não podem usar APIs de ambiente operacional como o Win32. Por que esses programas seriam necessários" Qualquer programa que deve ser executado antes que o subsistema Win32 seja iniciado (no momento em que a caixa de logon aparece) deve ser um aplicativo nativo. O exemplo mais visível de um aplicativo nativo é o programa "autochk" que executa chkdsk durante a inicialização Blue Screen (é o programa que imprime o "."' s no ecrã). Naturalmente, o servidor do ambiente operacional Win32, CSRSS.EXE (Client-Server Runtime Subsystem), também deve ser um aplicativo nativo.

Neste artigo, vou descrever como os aplicativos nativos são criados e como funcionam.

Como o Autochk é executado

O Autochk é executado entre o momento em que os drivers de inicialização e inicialização do sistema do NT são carregados e quando a paginação está ativada. Neste ponto da sequência de inicialização, o Gerenciador de Sessões (smss.exe) está deixando o ambiente de modo de usuário do NT pronto e nenhum outro programa está ativo. O valor HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute , um MULTI_SZ, contém os nomes e argumentos de programas que são executados pelo Session Manager e é onde Autochk é especificado. Aqui está o que você normalmente encontrará se olhar para esse valor, onde "Autochk" é passado "*" como um argumento:

Autocheck Autochk *

O Gestor de Sessões procura no <diretório winnt>\system32 os executáveis listados neste valor. Quando o Autochk é executado, não há arquivos abertos para que o Autochk possa abrir qualquer volume no modo bruto, incluindo a unidade de inicialização, e manipular suas estruturas de dados no disco. Isso não seria possível em nenhum momento posterior.

Criando aplicativos nativos

A Microsoft não documenta isso, mas o utilitário NT DDK Build sabe como criar aplicativos nativos (e provavelmente é usado para compilar o Autochk). Você especifica informações em um arquivo SOURCES que define o aplicativo, o mesmo que seria feito para drivers de dispositivo. No entanto, em vez de indicar para Build que você deseja um driver, você diz que deseja um aplicativo nativo no arquivo SOURCES como este:

TARGETTYPE=PROGRAM

O utilitário Build usa um makefile padrão para guiá-lo, \ddk\inc\makefile.def, que procura uma biblioteca de tempo de execução chamada nt.lib ao compilar aplicativos nativos. Infelizmente, a Microsoft não envia este arquivo com o DDK (está incluído no DDK Server 2003, mas suspeito que se você vincular com essa versão, seu aplicativo nativo não será executado no XP ou Windows 2000). No entanto, você pode contornar esse problema incluindo uma linha em makefile.def que substitui a seleção de nt.lib especificando a biblioteca de tempo de execução do Visual C++, msvcrt.lib

Se você executar o Build no ambiente "Checked Build" do DDK, ele produzirá um aplicativo nativo com informações completas de depuração em %BASEDIR%\lib%CPU%\Checked (por exemplo, c:\ddk\lib\i386\checked\native.exe), e se você invocá-lo no ambiente "Free Build ", uma versão de lançamento do programa acabará em %BASEDIR%\lib%CPU%\Free. Estes são os mesmos lugares onde as imagens do driver de dispositivo são colocadas pela Build.

Os aplicativos nativos têm extensões de arquivo ".exe", mas você não pode executá-los como o Win32 .exe. Se você tentar, receberá a mensagem:

O aplicativo não pode ser executado no modo Windows NT.

Dentro de um aplicativo nativo

Em vez de winmain ou main, o ponto de entrada para aplicativos nativos é NtProcessStartup. Também ao contrário dos outros pontos de entrada do Win32, os aplicativos nativos devem alcançar uma estrutura de dados passada como seu único parâmetro para localizar argumentos de linha de comando.

A maioria do ambiente de tempo de execução de um aplicativo nativo é fornecida pelo NTDLL.DLL, a biblioteca de exportação de API nativa da NT. Os aplicativos nativos devem criar seu próprio heap a partir do qual alocar armazenamento usando RtlCreateHeap, uma função NTDLL. A memória é alocada a partir de uma pilha com RtlAllocateHeap e liberada com RtlFreeHeap. Se um aplicativo nativo deseja imprimir algo na tela, ele deve usar a função NtDisplayString, que será saída para a inicialização Blue Screen.

Aplicativos nativos não simplesmente retornam de sua função de inicialização como programas Win32, uma vez que não há código de tempo de execução para retornar. Em vez disso, eles devem se encerrar chamando NtProcessTerminate.

O tempo de execução NTDLL consiste em centenas de funções que permitem que aplicativos nativos executem E/S de arquivos, interajam com drivers de dispositivo e executem comunicações entre processos. Infelizmente, como afirmei anteriormente, a grande maioria destas funções não está documentada.