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". Natywny interfejs API jest głównie nieudokumentowany, z zaledwie 25 z jego 250 funkcji opisanych w zestawie sterowników urządzeń z systemem Windows NT.
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 chkdsk podczas inicjowania Blue Screen (jest to program, który drukuje "." s na ekranie). Oczywiście serwer środowiska operacyjnego Win32, CSRSS.EXE (podsystem środowiska uruchomieniowego client-server), musi być również aplikacją natywną.
W tym artykule opiszę sposób tworzenia aplikacji natywnych i sposobu ich działania.
Jak jest wykonywane autochk
Autochk działa między czasem ładowania sterowników rozruchu nt i uruchamiania systemu, a po włączeniu stronicowania. W tym momencie w Menedżerze sesji rozruchu (smss.exe) jest pobieranie środowiska trybu użytkownika NT poza ziemią i żadne inne programy nie są aktywne. HKLM \System\CurrentControlSet\Control\Session Manager\BootExecute wartość, MULTI_SZ, zawiera nazwy i argumenty programów wykonywanych przez Menedżera sesji i jest miejscem, w którym określono autochk. Oto, co zwykle znajdziesz, jeśli spojrzysz na tę wartość, gdzie "Autochk" jest przekazywany "*" jako argument:
Autocheck Autochk *
Menedżer sesji wyszukuje w <katalogu winnt>\system32 dla plików wykonywalnych wymienionych w tej wartości. 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
Firma 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ć kompilację, którą chcesz utworzyć sterownik, należy poinformować o tym, że aplikacja natywna ma być w pliku SOURCES w następujący sposób:
TARGETTYPE=PROGRAM
Narzędzie kompilacji używa standardowego pliku makefile, aby go kierować, \ddk\inc\makefile.def, która wyszukuje bibliotekę czasu wykonywania o nazwie nt.lib podczas kompilowania aplikacji natywnych. Niestety, firma Microsoft nie dostarcza tego pliku z zestawem DDK (dołączonym do zestawu DDK Server 2003, ale podejrzewam, że jeśli łączysz się z tą wersją, aplikacja natywna nie będzie działać 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 polecenie Build w środowisku "Sprawdzona kompilacja" zestawu DDK, spowoduje to wygenerowanie aplikacji natywnej z pełnymi informacjami debugowania w obszarze %BASEDIR%\lib%\CPU%\Checked (np. c:\ddk\lib\i386\checked\native.exe), a jeśli wywołasz ją w środowisku "Bezpłatna kompilacja", wersja wydania programu zakończy się w %BASEDIR%\lib%CPU%\Free. Są to te same miejsca, w których obrazy sterowników urządzeń są umieszczane przez kompilację.
Aplikacje natywne mają rozszerzenia plików ".exe", ale nie można ich uruchomić, takich jak Win32 .exe. 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 jest udostępniana przez NTDLL.DLL natywną bibliotekę eksportu interfejsu API NT. Aplikacje natywne muszą utworzyć własną stertę, z której można przydzielić magazyn przy użyciu funkcji RtlCreateHeap, funkcji NTDLL. Pamięć jest przydzielana z sterta z RtlAllocateHeap i zwalniana z RtlFreeHeap. Jeśli aplikacja natywna chce wydrukować coś na ekranie, musi użyć funkcji NtDisplayString, która zwróci dane wyjściowe do inicjowania Blue Screen.
Aplikacje natywne nie są po prostu zwracane z funkcji uruchamiania, takiej jak programy Win32, ponieważ nie ma kodu środowiska uruchomieniowego do powrotu. 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.