Wewnątrz aplikacji natywnych

Mark Russinovich Opublikowano: 1 listopada 2006 r.

Wprowadzenie

Jeśli masz pewną znajomość architektury NT, prawdopodobnie wiesz, że interfejs API używany przez aplikacje Win32 nie jest "prawdziwym" interfejsem API NT. Środowiska operacyjne NT, w tym POSIX, OS/2 i Win32, komunikują się z aplikacjami klienckimi za pośrednictwem własnych interfejsów API, ale rozmawiają z NT przy użyciu interfejsu API "natywnego". Natywne API pozostaje w większości nieudokumentowane; w pakiecie Windows NT Device Driver Kit opisano jedynie około 25 z jego 250 funkcji.

Większość osób nie wie jednak, że "natywne" aplikacje istnieją w NT, które nie są klientami żadnego ze środowisk operacyjnych. Te programy mówią o natywnym interfejsie API NT i nie mogą używać interfejsów API środowiska operacyjnego, takich jak Win32. Dlaczego takie programy powinny być potrzebne" Każdy program, który musi działać przed uruchomieniem podsystemu Win32 (w czasie pojawiania się pola logowania) musi być aplikacją natywną. Najbardziej widocznym przykładem aplikacji natywnej jest program „autochk”, który uruchamia narzędzie chkdsk podczas inicjalizacji na niebieskim ekranie (to program, który wyświetla na ekranie znaki „.”). Oczywiście serwer środowiska operacyjnego Win32, CSRSS.EXE ( podsystem środowiska uruchomieniowegoClient-Server), musi być również aplikacją natywną.

W tym artykule opiszę sposób tworzenia aplikacji natywnych i sposobu ich działania.

Jak jest uruchamiany Autochk

Autochk działa w okresie pomiędzy załadowaniem sterowników rozruchowych i startowych systemu NT a włączeniem stronicowania. W tym momencie sekwencji rozruchu Menedżer sesji (smss.exe) uruchamia środowisko trybu użytkownika systemu NT i żadne inne programy nie są jeszcze uruchomione. Wartość HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute typu MULTI_SZ zawiera nazwy i argumenty programów wykonywanych przez Menedżera sesji i to w niej określono Autochk. Oto, co zazwyczaj zobaczysz, jeśli przyjrzysz się tej wartości, gdy program „Autochk” otrzymuje argument „*”:

Autocheck Autochk *

Menedżer sesji wyszukuje pliki wykonywalne wymienione w tej wartości w katalogu <winnt>\system32. Gdy autochk działa, nie ma otwartych plików, więc autochk może otworzyć dowolny wolumin w trybie nieprzetworzonym, w tym dysk rozruchowy, i manipulować jego strukturami danych na dysku. Nie byłoby to możliwe w żadnym późniejszym momencie.

Tworzenie aplikacji natywnych

Microsoft nie dokumentuje go, ale narzędzie NT DDK Build wie, jak tworzyć aplikacje natywne (i prawdopodobnie używane do kompilowania autochk). Należy określić informacje w pliku SOURCES, który definiuje aplikację, tak samo jak w przypadku sterowników urządzeń. Jednak zamiast wskazywać narzędziu Build, że chcesz sterownik, podajesz w pliku SOURCES, że chcesz aplikację natywną, w następujący sposób:

TARGETTYPE=PROGRAM

Narzędzie Build używa standardowego pliku makefile, \ddk\inc\makefile.def, jako wskazówek, który podczas kompilowania aplikacji natywnych wyszukuje bibliotekę wykonawczą o nazwie nt.lib. Niestety, Microsoft nie dostarcza tego pliku z zestawem DDK (dołączonym do zestawu DDK Server 2003, ale podejrzewam, że jeśli połączysz się z tą wersją, aplikacja natywna nie zostanie uruchomiona w systemie XP lub Windows 2000). Można jednak obejść ten problem, dołączając wiersz w pliku makefile.def, który zastępuje wybór nt.lib, określając bibliotekę środowiska uruchomieniowego języka Visual C++, msvcrt.lib

Jeśli uruchomisz Build w środowisku DDK „Checked Build”, zostanie utworzona aplikacja natywna z pełnymi informacjami debugowymi pod %BASEDIR%\lib%CPU%\Checked (np. c:\ddk\lib\i386\checked\native.exe), a jeśli uruchomisz je w środowisku „Free Build”, wersja wydaniowa programu trafi do %BASEDIR%\lib%CPU%\Free. Są to te same lokalizacje, w których Build umieszcza obrazy sterowników.

Aplikacje natywne mają rozszerzenia plików ".exe", ale nie można ich uruchomić, takich jak Win32 .exe' s. Jeśli spróbujesz, otrzymasz komunikat:

Nie można uruchomić aplikacji w trybie Windows NT.

Wewnątrz aplikacji natywnej

Zamiast winmain lub main punkt wejścia dla aplikacji natywnych to NtProcessStartup. Również w przeciwieństwie do innych punktów wejścia Win32, aplikacje natywne muszą dotrzeć do struktury danych przekazanej jako jedyny parametr, aby zlokalizować argumenty wiersza polecenia.

Większość środowiska uruchomieniowego aplikacji natywnej zapewnia NTDLL.DLL, biblioteka eksportu natywnego interfejsu API systemu NT. Aplikacje natywne muszą utworzyć własną stertę, z której mają przydzielać pamięć za pomocą funkcji RtlCreateHeap z biblioteki NTDLL. Pamięć jest przydzielana ze sterty za pomocą RtlAllocateHeap i zwalniana za pomocą RtlFreeHeap. Jeśli aplikacja natywna chce wyświetlić coś na ekranie, musi użyć funkcji NtDisplayString, która wyświetli to na ekranie inicjalizacyjnym Blue Screen.

Aplikacje natywne nie kończą po prostu działania przez powrót z funkcji startowej, tak jak programy Win32, ponieważ nie ma kodu wykonawczego, do którego można wrócić. Zamiast tego muszą zakończyć się przez wywołanie NtProcessTerminate.

Środowisko uruchomieniowe NTDLL składa się z setek funkcji, które umożliwiają natywnym aplikacjom wykonywanie operacji we/wy plików, interakcję ze sterownikami urządzeń i wykonywanie komunikacji międzyprocesowej. Niestety, jak stwierdziłem wcześniej, zdecydowana większość tych funkcji jest nieudokumentowana.