In nativen Anwendungen

Mark Russinovich veröffentlicht: 1. November 2006

Einführung

Wenn Sie mit der Architektur von NT vertraut sind, wissen Sie wahrscheinlich, dass die API, die Win32-Anwendungen verwenden, nicht die "echte" NT-API ist. Die Betriebssystemumgebungen von NT, die POSIX, OS/2 und Win32 enthalten, sprechen über ihre eigenen APIs mit ihren Clientanwendungen, sprechen aber mit NT über die "native" NT-API. Die native API ist hauptsächlich nicht dokumentiert, wobei nur etwa 25 seiner 250 Funktionen im Windows NT Device Driver Kit beschrieben sind.

Was die meisten Personen jedoch nicht wissen, ist, dass "systemeigene" Anwendungen auf NT vorhanden sind, die keine Clients einer der Betriebssystemumgebungen sind. Diese Programme sprechen die native NT-API und können keine Betriebssystemumgebungs-APIs wie Win32 verwenden. Warum würden solche Programme benötigt" Jedes Programm, das ausgeführt werden muss, bevor das Win32-Subsystem gestartet wird (um die Zeit, in der das Anmeldefeld angezeigt wird), muss eine systemeigene Anwendung sein. Das sichtbarste Beispiel für eine native Anwendung ist das Programm „autochk“, das chkdsk während des blauen Initialisierungsbildschirms ausführt (es ist das Programm, das die Punkte („.“) auf dem Bildschirm ausgibt). Natürlich muss der Win32-Betriebssystemumgebungsserver CSRSS.EXE (Client-Server Runtime Subsystem) auch eine systemeigene Anwendung sein.

In diesem Artikel werde ich beschreiben, wie native Anwendungen erstellt werden und wie sie funktionieren.

Wie wird Autochk ausgeführt?

Autochk wird zwischen dem Zeitpunkt ausgeführt, zu dem NT-Start- und Systemstarttreiber geladen werden, und wenn paging aktiviert ist. Zu diesem Zeitpunkt im Startvorgang initialisiert der Session Manager (smss.exe) die User-Mode-Umgebung von NT, und es sind keine anderen Programme aktiv. Der Wert "HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute ", ein MULTI_SZ, enthält die Namen und Argumente von Programmen, die vom Session Manager ausgeführt werden, und ist der Ort, an dem Autochk angegeben wird. Folgendes finden Sie in der Regel, wenn Sie sich diesen Wert ansehen und dabei an „Autochk“ „*“ als Argument übergeben wird:

Autocheck Autochk *

Der Sitzungs-Manager sucht im <Verzeichnis "winnt>\system32" nach den ausführbaren Dateien, die in diesem Wert aufgeführt sind. Wenn Autochk ausgeführt wird, sind keine Dateien geöffnet, sodass Autochk jedes Volume im unformatierten Modus öffnen kann, einschließlich des Startlaufwerks, und seine Datenträgerdatenstrukturen bearbeiten kann. Dies wäre zu einem späteren Zeitpunkt nicht möglich.

Erstellen nativer Anwendungen

Microsoft dokumentiert es nicht, aber das NT DDK Build-Hilfsprogramm weiß, wie systemeigene Anwendungen erstellt werden (und die wahrscheinlich zum Kompilieren von Autochk verwendet werden). Sie geben Informationen in einer SOURCES-Datei an, die die Anwendung definiert, genauso wie bei Gerätetreibern. Statt Build jedoch anzugeben, dass Sie einen Treiber wünschen, teilen Sie ihm in der SOURCES-Datei wie folgt mit, dass Sie eine native Anwendung wünschen:

TARGETTYPE=PROGRAM

Das Build-Hilfsprogramm verwendet eine Standard-Makefile zur Anleitung, \ddk\inc\makefile.def, die beim Kompilieren systemeigener Anwendungen nach einer Laufzeitbibliothek mit dem Namen nt.lib sucht. Leider liefert Microsoft diese Datei nicht mit dem DDK aus (im Server 2003 DDK ist sie zwar enthalten, aber ich vermute, dass Ihre native Anwendung unter XP oder Windows 2000 nicht ausgeführt werden kann, wenn Sie gegen diese Version linken). Sie können dieses Problem jedoch umgehen, indem Sie eine Zeile in makefile.def einschließen, die die Auswahl von nt.lib überschreibt, indem Sie die Laufzeitbibliothek von Visual C++, msvcrt.lib, angeben.

Wenn Sie Build unter der DDK-Umgebung "Checked Build" ausführen, wird eine systemeigene Anwendung mit vollständigen Debuginformationen unter %BASEDIR%\lib%CPU%\Checked (z. B. c:\ddk\lib\i386\checked\native.exe) erstellt, und wenn Sie sie in der Umgebung "Free Build" aufrufen, wird eine Releaseversion des Programms in %BASEDIR%\lib%CPU%\Free enden. Dies sind die gleichen Orte, an denen Gerätetreiberimages von Build platziert werden.

Systemeigene Anwendungen verfügen über ".exe"-Dateierweiterungen, aber Sie können sie nicht wie Win32 .exe's ausführen. Wenn Sie versuchen, erhalten Sie die Nachricht:

Die Anwendung kann nicht im NT-Modus Windows ausgeführt werden.

Innerhalb einer nativen Anwendung

Anstelle von winmain oder main ist der Einstiegspunkt für systemeigene Anwendungen NtProcessStartup. Im Gegensatz zu den anderen Win32-Einstiegspunkten müssen systemeigene Anwendungen in eine Datenstruktur gelangen, die als alleiniger Parameter übergeben wird, um Befehlszeilenargumente zu finden.

Der Großteil der Laufzeitumgebung einer nativen Anwendung wird von NTDLL.DLL, der nativen API-Exportbibliothek von NT, bereitgestellt. Systemeigene Anwendungen müssen einen eigenen Heap erstellen, aus dem mithilfe von RtlCreateHeap, einer NTDLL-Funktion, Speicher zugewiesen werden soll. Der Speicher wird von einem Heap mit RtlAllocateHeap zugewiesen und mit RtlFreeHeap freigegeben. Wenn eine systemeigene Anwendung etwas auf dem Bildschirm drucken möchte, muss sie die Funktion NtDisplayString verwenden, die in die Initialisierung Blue Screen ausgegeben wird.

Native Anwendungen kehren nicht einfach wie Win32-Programme aus ihrer Startfunktion zurück, da es keinen Laufzeitcode gibt, zu dem sie zurückkehren könnten. Stattdessen müssen sie sich selbst beenden, indem sie NtProcessTerminate aufrufen.

Die NTDLL-Laufzeit besteht aus Hunderten von Funktionen, mit denen systemeigene Anwendungen Datei-E/A ausführen, mit Gerätetreibern interagieren und Interprocess-Kommunikationen durchführen können. Leider, wie ich bereits erwähnt habe, sind die meisten dieser Funktionen nicht dokumentiert.