Binnen natuurlijke toepassingen

Mark Russinovich Gepubliceerd: 1 november 2006

Inleiding

Als u bekend bent met de architectuur van NT, weet u waarschijnlijk dat de API die Win32-toepassingen gebruiken niet de echte NT-API is. De besturingsomgevingen van NT, waaronder POSIX, OS/2 en Win32, communiceren met hun clienttoepassingen via hun eigen API's, maar communiceren met NT met behulp van de NT -systeemeigen API. De systeemeigen API is voornamelijk niet-gedocumenteerd, met slechts ongeveer 25 van de 250 functies die worden beschreven in de Windows NT Device Driver Kit.

Wat de meeste mensen niet weten, is dat 'systeemeigen' toepassingen bestaan op NT die geen clients van een van de besturingsomgevingen zijn. Deze programma's spreken de systeemeigen NT-API en kunnen geen API's voor de bedrijfsomgeving gebruiken, zoals Win32. Waarom zouden dergelijke programma's nodig zijn" Elk programma dat moet worden uitgevoerd voordat het Win32-subsysteem wordt gestart (rond het moment dat het aanmeldingsvak wordt weergegeven) moet een systeemeigen toepassing zijn. Het meest zichtbare voorbeeld van een native toepassing is het programma 'autochk', dat chkdsk uitvoert tijdens het blauwe initialisatiescherm (het programma dat de punten "." op het scherm weergeeft). De Win32-besturingssysteemserver, CSRSS.EXE (Client-Server Runtime-subsysteem), moet natuurlijk ook een systeemeigen toepassing zijn.

In dit artikel ga ik beschrijven hoe systeemeigen toepassingen worden gebouwd en hoe ze werken.

Hoe wordt Autochk uitgevoerd

Autochk wordt uitgevoerd tussen de tijd dat de opstart- en systeemstartstuurprogramma's van NT worden geladen en wanneer paging is ingeschakeld. Op dit punt in de opstartvolgorde brengt Sessiebeheer (smss.exe) NT's gebruikersmodusomgeving op gang en zijn er geen andere programma's actief. De waarde HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute , een MULTI_SZ, bevat de namen en argumenten van programma's die worden uitgevoerd door Session Manager en is waar Autochk is opgegeven. Dit is wat u doorgaans zult vinden als u deze waarde bekijkt, waarbij 'Autochk' wordt doorgegeven als argument:

Autocheck Autochk *

Session Manager zoekt in de map <winnt>\system32 naar de uitvoerbare bestanden die in deze waarde zijn vermeld. Wanneer Autochk wordt uitgevoerd, zijn er geen bestanden geopend, zodat Autochk elk volume in de onbewerkte modus kan openen, inclusief het opstartstation en de bijbehorende gegevensstructuren op schijf kan manipuleren. Dit zou later niet mogelijk zijn.

Systeemeigen toepassingen bouwen

Microsoft documenteer het niet, maar het NT DDK Build-hulpprogramma weet hoe systeemeigen toepassingen te maken (en het waarschijnlijk wordt gebruikt om Autochk te compileren). U geeft informatie op in een SOURCES-bestand dat de toepassing definieert, hetzelfde als voor apparaatstuurprogramma's. In plaats van Build aan te geven dat u een stuurprogramma wilt, geeft u op dat u een native toepassing in het SOURCES-bestand wilt, als volgt:

TARGETTYPE=PROGRAM

Het buildhulpprogramma maakt gebruik van een standaard makefile om dit te begeleiden, \ddk\inc\makefile.def, die zoekt naar een runtimebibliotheek met de naam nt.lib bij het compileren van systeemeigen toepassingen. Helaas verzendt Microsoft dit bestand niet met de DDK (opgenomen in de Server 2003 DDK, maar ik vermoed dat als u een koppeling maakt met die versie, uw systeemeigen toepassing niet wordt uitgevoerd op XP of Windows 2000). U kunt dit probleem echter omzeilen door een regel op te nemen in makefile.def die de selectie van nt.lib overschrijft door de runtimebibliotheek van Visual C++, msvcrt.lib, op te geven

Als u Build uitvoert onder de omgeving 'Checked Build' van de DDK, wordt er een systeemeigen toepassing geproduceerd met volledige foutopsporingsgegevens onder %BASEDIR%\lib%CPU%\Checked (bijvoorbeeld c:\ddk\lib\i386\checked\native.exe), en als u deze aanroept in de omgeving 'Gratis build', eindigt een releaseversie van het programma in %BASEDIR%\lib%CPU%\Free. Dit zijn dezelfde locaties waar installatiekopieën van apparaatstuurprogramma's door Build worden geplaatst.

Systeemeigen toepassingen hebben ".exe" bestandsextensies, maar u kunt ze niet uitvoeren zoals Win32 .exe's. Als u het probeert, krijgt u het volgende bericht:

De toepassing kan niet worden uitgevoerd in Windows NT-modus.

Binnen een systeemeigen toepassing

In plaats van winmain of main is het toegangspunt voor systeemeigen toepassingen NtProcessStartup. Ook in tegenstelling tot de andere Win32-ingangspunten moeten native toepassingen in een gegevensstructuur zoeken die als enige parameter wordt doorgegeven om de opdrachtregelargumenten te achterhalen.

Het merendeel van de runtime-omgeving van een systeemeigen toepassing wordt geleverd door NTDLL.DLL, de systeemeigen API-exportbibliotheek van NT. Systeemeigen toepassingen moeten hun eigen heap maken waaruit opslag moet worden toegewezen met behulp van RtlCreateHeap, een NTDLL-functie. Geheugen wordt toegewezen vanaf een heap met RtlAllocateHeap en vrijgemaakt met RtlFreeHeap. Als een systeemeigen toepassing iets op het scherm wil afdrukken, moet de functie NtDisplayString worden gebruikt, die wordt uitgevoerd naar het initialisatieblauw scherm.

Native toepassingen keren niet simpelweg terug uit hun opstartfunctie, zoals Win32-programma's dat doen, omdat er geen runtimecode is om naar terug te keren. In plaats daarvan moeten ze zichzelf beëindigen door NtProcessTerminate aan te roepen.

De NTDLL-runtime bestaat uit honderden functies waarmee systeemeigen toepassingen I/O-bestanden kunnen uitvoeren, kunnen communiceren met apparaatstuurprogramma's en communicatie tussen processen kunnen uitvoeren. Zoals ik al eerder heb gezegd, zijn de overgrote meerderheid van deze functies helaas niet gedocumenteerd.