Approfondimento sulle applicazioni native

Mark Russinovich Data di pubblicazione: 1 novembre 2006

Introduzione

Se si ha familiarità con l'architettura di NT, è probabile che si sia consapevoli del fatto che l'API usata dalle applicazioni Win32 non è l'API NT "reale". Gli ambienti operativi di NT, che includono POSIX, OS/2 e Win32, comunicano con le applicazioni client tramite le proprie API, ma parlano con NT usando l'API "nativa" NT. L'API nativa è per lo più non documentata, con solo 25 delle 250 funzioni descritte in Windows NT Device Driver Kit.

Ciò che la maggior parte delle persone non sa, tuttavia, è che in NT esistono applicazioni "native" che non sono client di nessuno degli ambienti operativi. Questi programmi parlano il linguaggio dell'API NT nativa e non possono usare API dell'ambiente operativo come Win32. Perché questi programmi dovrebbero essere necessari? Qualsiasi programma che deve essere eseguito prima dell'avvio del sottosistema Win32 (nel momento in cui viene visualizzata la casella di accesso) deve essere un'applicazione nativa. L'esempio più visibile di un'applicazione nativa è il programma "autochk" che esegue chkdsk durante l'inizializzazione Blue Screen (è il programma che stampa "."' s sullo schermo). Naturalmente, anche il server dell'ambiente operativo Win32, CSRSS.EXE (Client-Server Runtime Subsystem), deve essere un'applicazione nativa.

In questo articolo verrà descritto il modo in cui vengono create le applicazioni native e come funzionano.

Come viene eseguito Autochk

Autochk viene eseguito nel periodo tra il caricamento dei driver di boot e di avvio del sistema NT e l'attivazione del paging. A questo punto nella sequenza di avvio Session Manager (smss.exe) sta attivando l'ambiente in modalità utente NT e nessun altro programma è attivo. Il valore HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute, un MULTI_SZ, contiene i nomi e gli argomenti dei programmi eseguiti da Session Manager ed è la posizione in cui viene specificato Autochk. Ecco ciò che si trova in genere osservando questo valore, in cui ad "Autochk" viene passato "*" come argomento:

Autocheck Autochk *

Session Manager cerca nella directory <winnt>\system32 i file eseguibili elencati in questo valore. Quando Autochk viene eseguito non sono presenti file aperti in modo che Autochk possa aprire qualsiasi volume in modalità non elaborata, inclusa l'unità di avvio e modificare le relative strutture di dati su disco. Questo non sarebbe possibile in una qualsiasi fase successiva.

Compilazione di applicazioni native

Microsoft non lo documenta, ma l'utilità NT DDK Build sa come compilare applicazioni native (ed è probabilmente usata per compilare Autochk). Le informazioni vengono specificate in un file SOURCES che definisce l'applicazione, come per i driver di dispositivo. Tuttavia, invece di indicare a Build that you want a driver , you tell it want a native application in the SOURCES file like this:, invece di indicare a Build that you want a driver, you tell it want a native application in the SOURCES file like this:

TARGETTYPE=PROGRAM

L'utilità Bukld usa un makefile standard come guida, \ddk\inc\makefile.def, che cerca una libreria di runtime denominata nt.lib durante la compilazione di applicazioni native. Sfortunatamente, Microsoft non fornisce questo file con il DDK (è incluso in Server 2003 DDK, ma sospetto che collegandosi a tale versione l'applicazione nativa non verrà eseguita su XP o Windows 2000). Tuttavia, è possibile risolvere questo problema includendo una riga in makefile.def che esegue l'override della selezione di nt.lib specificando la libreria di runtime di Visual C++, msvcrt.lib

Se si esegue Build nell'ambiente "Checked Build" del DDK, verrà generata un'applicazione nativa con informazioni di debug complete in %BASEDIR%\lib%CPU%\Checked (ad esempio c:\ddk\lib\i386\checked\native.exe) e se la si richiama nell'ambiente "Free Build" una versione di rilascio del programma finirà in %BASEDIR%\lib%CPU%\Free. Queste sono le stesse posizioni in cui Build posiziona le immagini di driver di dispositivo.

Le applicazioni native hanno estensioni di file "exe", ma non è possibile eseguirle come EXE Win32. Se si prova si otterrà il messaggio:

L'applicazione non può essere eseguita in modalità Windows NT.

Meccanismi interni di un'applicazione nativa

Invece di winmain o main, il punto di ingresso per le applicazioni native è NtProcessStartup. A differenza degli altri punti di ingresso Win32, le applicazioni native devono raggiungere una struttura di dati passata come unico parametro per individuare gli argomenti della riga di comando.

La maggior parte dell'ambiente di runtime di un'applicazione nativa è fornita da NTDLL.DLL, la libreria di esportazione dell'API nativa di NT. Le applicazioni native devono creare un proprio heap da cui allocare spazio di archiviazione usando RtlCreateHeap, una funzione NTDLL. La memoria viene allocata da un heap con RtlAllocateHeap e liberata con RtlFreeHeap. Se un'applicazione nativa desidera stampare qualcosa sullo schermo, deve usare la funzione NtDisplayString, che restituirà la schermata blu di inizializzazione.

Le applicazioni native non escono semplicemente dalla funzione di avvio, come i programmi Win32, perché non esiste codice di runtime a cui tornare. Al contrario, devono essere terminate chiamando NtProcessTerminate.

Il runtime NTDLL è costituito da centinaia di funzioni che consentono alle applicazioni native di eseguire operazioni di I/O di file, interagire con i driver di dispositivo ed eseguire comunicazioni interprocesso. Purtroppo, come accennato in precedenza, la maggior parte di queste funzioni non è documentata.