Natív alkalmazásokon belül

Mark Russinovich Megjelent: 2006. november 1.

Bevezetés

Ha ismeri az NT architektúráját, valószínűleg tisztában van azzal, hogy a Win32-alkalmazások által használt API nem a "valódi" NT API. Az NT operációs környezetei, például a POSIX, az OS/2 és a Win32, saját API-jukon keresztül beszélnek az ügyfélalkalmazásokkal, de az NT-hez az NT "natív" API-val beszélnek. A natív API többnyire nem dokumentált, és a Windows NT-eszközillesztő készletben leírt 250 függvényből csak körülbelül 25-öt ismertet.

A legtöbb ember azonban nem tudja, hogy a "natív" alkalmazások olyan NT-natív alkalmazások léteznek, amelyek nem az operációs környezetek egyikének ügyfelei sem. Ezek a programok a natív NT API-t használják, és nem használhatnak olyan operációs környezet API-kat, mint a Win32. Miért lenne szükség ilyen programokra? Minden olyan programnak natív alkalmazásnak kell lennie, amelyet a Win32 alrendszer elindítása előtt kell futtatni (a bejelentkezési mező megjelenése körül). A natív alkalmazások legláthatóbb példája az "autochk" program, amely chkdsk-t futtat az inicializálás kék képernyőjén (ez a program nyomtatja a "." s a képernyőn). Természetesen a Win32 operációs környezet kiszolgálójának, a CSRSS.EXE (ügyfél-kiszolgáló futtatókörnyezeti alrendszer) is natív alkalmazásnak kell lennie.

Ebben a cikkben bemutatom, hogyan épülnek fel a natív alkalmazások, és hogyan működnek.

Hogyan hajtja végre az Autochk a végrehajtást?

Az autochk az NT rendszerindítási és rendszerindítási illesztőprogramjainak betöltése és a lapozás bekapcsolása között fut. A rendszerindítási sorozat munkamenet-kezelője (smss.exe) ezen a ponton az NT felhasználói módú környezetét kapja le a földről, és más programok nem aktívak. A HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute érték, egy MULTI_SZ tartalmazza a Session Manager által végrehajtott programok nevét és argumentumait, és itt van megadva az Autochk. Általában ezt az értéket fogja megtalálni, ahol az "Autochk" argumentumként "*" lesz átadva:

Autocheck Autochk *

A Munkamenet-kezelő a <winnt>\system32 könyvtárban keresi meg az ebben az értékben felsorolt végrehajtható elemeket. Az Autochk futtatásakor nincsenek megnyitva fájlok, így az Autochk bármilyen kötetet megnyithat nyers módban, beleértve a rendszerindító meghajtót is, és módosíthatja a lemezen lévő adatstruktúrákat. Ez később nem lehetséges.

Natív alkalmazások létrehozása

A Microsoft nem dokumentálja, de az NT DDK Build segédprogram tudja, hogyan kell natív alkalmazásokat készíteni (és valószínűleg az Autochk fordításához használatos). Az alkalmazást meghatározó SOURCES-fájlban megadhatja az adatokat, ugyanúgy, mint az eszközillesztők esetében. Ahelyett azonban, hogy azt jelezi a Buildnek, hogy illesztőprogramot szeretne használni, azt kell mondania, hogy natív alkalmazást szeretne a SOURCES fájlban, például:

TARGETTYPE=PROGRAM

A Build segédprogram egy standard makefile használatával irányítja a \ddk\inc\makefile.def fájlt, amely natív alkalmazások összeállításakor keres egy nt.lib nevű futtatókörnyezeti kódtárat. Sajnos a Microsoft nem küldi el ezt a fájlt a DDK-val (annak része a Server 2003 DDK-ban, de gyanítom, hogy ha ezt a verziót csatolja, a natív alkalmazás nem fog futni XP vagy Windows 2000 rendszeren). A probléma megoldásához azonban be kell írnia egy sort a makefile.def fájlba, amely felülbírálja az nt.lib kiválasztását a Visual C++futtatókörnyezeti kódtára, az msvcrt.lib megadásával.

Ha a Buildet a DDK "Ellenőrzött build" környezetében futtatja, az létrehoz egy natív alkalmazást, amely teljes hibakeresési információkat tartalmaz a(z) %BA Standard kiadás DIR%\lib%CPU%\Checked (pl. c:\ddk\lib\i386\checked\native.exe) területen, és ha az "Ingyenes build" környezetben hívja meg, a program kiadási verziója %BA Standard kiadás DIR%\lib%CPU%\Free lesz. Ezek ugyanazok a helyek, ahol az eszközillesztő lemezképeit a Build helyezi el.

A natív alkalmazások ".exe" fájlkiterjesztéssel rendelkeznek, de nem futtathatók úgy, mint a Win32 .exe. Ha megpróbálja, az üzenet a következő lesz:

Az alkalmazás nem futtatható Windows NT módban.

Natív alkalmazáson belül

A winmain vagy a main helyett a natív alkalmazások belépési pontja az NtProcessStartup. A többi Win32 belépési ponttal ellentétben a natív alkalmazásoknak egyetlen paraméterként átadott adatstruktúrába kell eljutniuk a parancssori argumentumok megkereséséhez.

A natív alkalmazások futtatókörnyezetének többségét az NT natív API-exportálási kódtára, a NTDLL.DLL biztosítja. A natív alkalmazásoknak létre kell hozniuk a saját halomjukat, amelyből a tárterületet egy NTDLL-függvény, az RtlCreateHeap használatával lehet lefoglalni. A memória egy halomból van lefoglalva az RtlAllocateHeap segítségével, és az RtlFreeHeap segítségével szabadít fel. Ha egy natív alkalmazás ki szeretne nyomtatni valamit a képernyőn, az NtDisplayString függvényt kell használnia, amely az inicializálás kék képernyőjére fog kijönni.

A natív alkalmazások nem egyszerűen térnek vissza az indítási függvényükből, például a Win32-programokból, mivel nincs olyan futtatókörnyezeti kód, amelybe vissza lehet térni. Ehelyett az NtProcessTerminate meghívásával kell leállítaniuk magukat.

Az NTDLL-futtatókörnyezet több száz függvényből áll, amelyek lehetővé teszik a natív alkalmazások számára a fájl-I/O-műveletek végrehajtását, az eszközillesztőkkel való interakciót és a folyamatközi kommunikációt. Sajnos, amint azt korábban említettem, ezeknek a függvényeknek a túlnyomó többsége nincs dokumentálva.