À l’intérieur d’applications natives

Mark Russinovich Publié : 1er novembre 2006

Présentation

Si vous connaissez l’architecture de NT, vous savez probablement que l’API que les applications Win32 utilisent n’est pas l’API NT « réelle ». Les environnements d’exploitation de NT, qui incluent POSIX, OS/2 et Win32, communiquent avec leurs applications clientes via leurs propres API, mais communiquent avec NT à l’aide de l’API « native » NT. L’API native est principalement non documentée, avec seulement 25 de ses 250 fonctions décrites dans le kit de pilotes de périphérique NT Windows.

Ce que la plupart des gens ne savent pas, cependant, est que les applications « natives » existent sur NT qui ne sont pas des clients d’un des environnements d’exploitation. Ces programmes parlent l’API NT native et ne peuvent pas utiliser d’API d’environnement d’exploitation comme Win32. Pourquoi de tels programmes seraient-ils nécessaires » Tout programme qui doit s’exécuter avant le démarrage du sous-système Win32 (autour du moment où la zone d’ouverture de session s’affiche) doit être une application native. L’exemple le plus visible d’une application native est le programme « autochk » qui exécute chkdsk pendant l’initialisation de l’écran bleu (il s’agit du programme qui imprime le « ». s sur l’écran). Naturellement, le serveur d’environnement d’exploitation Win32, CSRSS.EXE (sous-système d’exécutionClient-Server), doit également être une application native.

Dans cet article, je vais décrire comment les applications natives sont générées et comment elles fonctionnent.

Comment Autochk est-il exécuté

Autochk s'exécute entre le moment où les pilotes de démarrage et de démarrage du système de NT sont chargés et le moment où la pagination est activée. À ce stade de la séquence de démarrage, le Gestionnaire de session (smss.exe) met en place l’environnement en mode utilisateur de NT, et aucun autre programme n’est en cours d’exécution. La valeur HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute , un MULTI_SZ, contient les noms et les arguments des programmes exécutés par le Gestionnaire de sessions, et est l’emplacement où autochk est spécifié. Voici ce que vous trouverez généralement lorsque vous examinez cette valeur, dans laquelle « Autochk » reçoit « * » comme argument :

Autocheck Autochk *

Le Gestionnaire de sessions recherche dans le <répertoire winnt>\system32 les exécutables répertoriés dans cette valeur. Lorsque autochk s’exécute, il n’existe aucun fichier ouvert afin que Autochk puisse ouvrir n’importe quel volume en mode brut, y compris le lecteur de démarrage, et manipuler ses structures de données sur disque. Cela ne serait pas possible à un moment ultérieur.

Création d’applications natives

Microsoft ne le documente pas, mais l’utilitaire Build du NT DDK sait créer des applications natives (et il est probablement utilisé pour compiler Autochk). Vous spécifiez des informations dans un fichier SOURCES qui définit l’application, de la même façon que pour les pilotes de périphérique. Toutefois, au lieu d’indiquer à Générer que vous souhaitez un pilote, vous indiquez qu’une application native se trouve dans le fichier SOURCES comme suit :

TARGETTYPE=PROGRAM

L’utilitaire build utilise un makefile standard pour le guider, \ddk\inc\makefile.def, qui recherche une bibliothèque runtime nommée nt.lib lors de la compilation d’applications natives. Malheureusement, Microsoft n'expédie pas ce fichier avec le DDK (inclus dans le DDK Server 2003, mais je soupçonne que si vous liez avec cette version, votre application native ne s'exécutera pas sur XP ou Windows 2000). Toutefois, vous pouvez contourner ce problème en incluant une ligne dans makefile.def qui remplace la sélection de nt.lib en spécifiant la bibliothèque runtime de Visual C++, msvcrt.lib

Si vous exécutez Build dans l’environnement « Checked Build » du DDK, cela génère une application native avec des informations de débogage complètes dans %BASEDIR%\lib%CPU%\Checked (par exemple, c:\ddk\lib\i386\checked\native.exe), et si vous l’exécutez dans l’environnement « Free Build », une version release du programme sera générée dans %BASEDIR%\lib%CPU%\Free. Ce sont les mêmes endroits où les images de pilote de périphérique sont placées par Build.

Les applications natives ont des extensions de fichier «.exe», mais vous ne pouvez pas les exécuter comme Win32 .exe's. Si vous essayez, vous recevrez le message suivant :

L’application ne peut pas être exécutée en mode NT Windows.

À l’intérieur d’une application native

Au lieu de winmain ou main, le point d’entrée pour les applications natives est NtProcessStartup. Contrairement aux autres points d’entrée Win32, les applications natives doivent accéder à une structure de données passée en tant que seul paramètre pour localiser les arguments de ligne de commande.

La majorité de l’environnement d’exécution d’une application native est fournie par NTDLL.DLL bibliothèque d’exportation d’API native de NT. Les applications natives doivent créer leur propre tas à partir duquel allouer du stockage à l’aide de RtlCreateHeap, une fonction NTDLL. La mémoire est allouée à partir d’un tas avec RtlAllocateHeap et libérée avec RtlFreeHeap. Si une application native souhaite imprimer quelque chose à l’écran, elle doit utiliser la fonction NtDisplayString, qui génère une sortie vers l’écran bleu d’initialisation.

Les applications natives ne se contentent pas de quitter leur fonction de démarrage, contrairement aux programmes Win32, car il n’existe aucun environnement d’exécution auquel revenir. Au lieu de cela, ils doivent eux-mêmes mettre fin à leur exécution en appelant NtProcessTerminate.

Le runtime NTDLL se compose de centaines de fonctions qui permettent aux applications natives d’effectuer des E/S de fichiers, d’interagir avec les pilotes de périphérique et d’effectuer des communications entre processus. Malheureusement, comme je l’ai dit précédemment, la grande majorité de ces fonctions ne sont pas documentées.