All'interno di applicazioni native

Mark Russinovich Pubblicato: 1 novembre 2006

Introduction

Se si ha familiarità con l'architettura di NT, è probabile che l'API usata dalle applicazioni Win32 non sia 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 è principalmente non documentata, con solo circa 25 delle sue 250 funzioni descritte in Windows NT Device Driver Kit.

Ciò che la maggior parte delle persone non sanno, tuttavia, è che le applicazioni "native" esistono in NT che non sono client di nessuno degli ambienti operativi. Questi programmi parlano l'API NT nativa e non possono usare API dell'ambiente operativo come Win32. Perché tali programmi sarebbero 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 sottosistema runtime), 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 compreso tra il caricamento dei driver di avvio e dei driver di sistema iniziali di NT e l'attivazione del paging. A questo punto della sequenza di avvio, Session Manager (smss.exe) sta mettendo in funzione l'ambiente in modalità utente di NT e nessun altro programma è in esecuzione. Il valore HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute, di tipo MULTI_SZ, contiene i nomi e gli argomenti dei programmi eseguiti da Gestione sessioni ed è qui che viene specificato Autochk. Ecco ciò che in genere troverai se osservi questo valore, dove "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 un secondo momento.

Compilazione di applicazioni native

Microsoft non lo documenta, ma l'utilità di compilazione NT DDK sa come rendere le applicazioni native (e probabilmente usato per compilare Autochk). Specificare le informazioni in un file SOURCES che definisce l'applicazione, come per i driver di dispositivo. Tuttavia, invece di indicare a Build che si desidera un driver, gli si dice che si desidera un'applicazione nativa nel file SOURCES, in questo modo:

TARGETTYPE=PROGRAM

L'utilità Di compilazione usa un makefile standard per guidarlo, \ddk\inc\makefile.def, che cerca una libreria di runtime denominata nt.lib durante la compilazione di applicazioni native. Sfortunatamente, Microsoft non spedirà questo file con il DDK (incluso in Server 2003 DDK, ma sospetto che se si collega 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" di 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 "Compilazione gratuita" una versione di rilascio del programma finirà in %BASEDIR%\lib%CPU%\Free. Queste sono le stesse posizioni in cui le immagini del driver di dispositivo vengono inserite da Build.

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

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

All'interno di un'applicazione nativa

Anziché winmain o main, il punto di ingresso per le applicazioni native è NtProcessStartup. Anche a differenza degli altri punti di ingresso Win32, le applicazioni native devono accedere a una struttura di dati passata loro come unico parametro per ricavare 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 si limitano a ritornare dalla funzione di avvio come i programmi Win32, poiché non esiste alcun codice di esecuzione a cui ritornare. Invece, devono terminare il processo autonomamente 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 ho detto in precedenza, la maggior parte di queste funzioni non è documentata.