Di dalam Aplikasi Native

Mark Russinovich Diterbitkan: 1 November 2006

Pendahuluan

Jika Anda memiliki keakraban dengan arsitektur NT, Anda mungkin menyadari bahwa API yang digunakan aplikasi Win32 bukan API NT "nyata". Lingkungan operasi NT, yang mencakup POSIX, OS/2 dan Win32, berbicara dengan aplikasi klien mereka melalui API mereka sendiri, tetapi berbicara dengan NT menggunakan API "asli" NT. API asli sebagian besar tidak terdokumentasi, dengan hanya sekitar 25 dari 250 fungsi yang dijelaskan dalam Windows NT Device Driver Kit.

Namun, yang tidak diketahui kebanyakan orang adalah bahwa aplikasi "asli" ada di NT yang bukan klien dari lingkungan operasi mana pun. Program-program ini berbicara API NT asli dan tidak dapat menggunakan API lingkungan operasi seperti Win32. Mengapa program tersebut diperlukan" Program apa pun yang harus berjalan sebelum subsistem Win32 dimulai (sekitar waktu kotak masuk muncul) harus menjadi aplikasi asli. Contoh yang paling jelas dari aplikasi native adalah program "autochk" yang menjalankan chkdsk selama inisialisasi Layar Biru (program inilah yang menampilkan tanda "." di layar). Secara alami, server lingkungan operasi Win32, CSRSS.EXE (Client-Server Subsistem Runtime), juga harus menjadi aplikasi asli.

Dalam artikel ini saya akan menjelaskan bagaimana aplikasi asli dibangun dan cara kerjanya.

Bagaimana Autochk Dieksekusi

Autochk berjalan di antara waktu di mana driver boot dan start sistem NT dimuat, dan ketika paging diaktifkan. Pada tahap ini dalam urutan boot, Session Manager (smss.exe) sedang menyiapkan lingkungan mode pengguna NT agar mulai berjalan, dan belum ada program lain yang aktif. Nilai HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute , MULTI_SZ, berisi nama dan argumen program yang dijalankan oleh Session Manager, dan merupakan tempat Autochk ditentukan. Berikut yang biasanya Anda temukan saat melihat nilai ini, ketika "Autochk" diberikan argumen "*":

Autocheck Autochk *

Manajer Sesi mencari berkas eksekusi yang tercantum pada nilai ini di direktori <winnt>\system32. Ketika Autochk berjalan tidak ada file yang terbuka sehingga Autochk dapat membuka volume apa pun dalam mode mentah, termasuk boot drive, dan memanipulasi struktur data pada disknya. Ini tidak akan mungkin terjadi di lain waktu.

Membangun Aplikasi Asli

Microsoft tidak mendokumenkannya, tetapi utilitas NT DDK Build tahu cara membuat aplikasi asli (dan mungkin digunakan untuk mengompilasi Autochk). Anda menentukan informasi dalam file SOURCES yang menentukan aplikasi, sama seperti yang akan dilakukan untuk driver perangkat. Namun, alih-alih menunjukkan ke Build bahwa Anda menginginkan driver, Anda memberi tahunya bahwa Anda menginginkan aplikasi asli dalam file SOURCES seperti ini:

TARGETTYPE=PROGRAM

Utilitas Build menggunakan makefile standar untuk memandunya, \ddk\inc\makefile.def, yang mencari pustaka run-time bernama nt.lib saat mengompilasi aplikasi asli. Sayangnya, Microsoft tidak mengirimkan file ini dengan DDK (termasuk dalam Server 2003 DDK, tetapi saya menduga bahwa jika Anda menautkan dengan versi tersebut aplikasi asli Anda tidak akan berjalan pada XP atau Windows 2000). Namun, Anda dapat mengatasi masalah ini dengan menyertakan baris dalam makefile.def yang mengesampingkan pemilihan nt.lib dengan menentukan pustaka runtime Visual C++, yaitu msvcrt.lib

Jika Anda menjalankan Build di bawah lingkungan "Checked Build" DDK, itu akan menghasilkan aplikasi asli dengan informasi debug lengkap di bawah %BASEDIR%\lib%CPU%\Checked (misalnya c:\ddk\lib\i386\checked\native.exe), dan jika Anda memanggilnya di lingkungan "Free Build" versi rilis program akan berakhir di %BASEDIR%\lib%CPU%\Free. Tempat-tempat ini adalah tempat yang sama yang digunakan Build untuk menempatkan image driver perangkat.

Aplikasi asli memiliki ekstensi file ".exe" tetapi Anda tidak dapat menjalankannya seperti Win32 .exe. Jika Anda mencoba, Anda akan mendapatkan pesan:

Aplikasi tidak dapat dijalankan dalam mode Windows NT.

Di dalam Aplikasi Asli

Alih-alih winmain atau utama, titik masuk untuk aplikasi asli adalah NtProcessStartup. Berbeda dengan entry point Win32 lainnya, aplikasi native harus mengakses struktur data yang diteruskan sebagai satu-satunya parameter untuk menemukan argumen baris perintah.

Sebagian besar lingkungan runtime dari aplikasi native disediakan oleh NTDLL.DLL, pustaka ekspor API native NT. Aplikasi native harus membuat heap mereka sendiri untuk mengalokasikan memori dengan menggunakan RtlCreateHeap, sebuah fungsi dalam NTDLL. Memori dialokasikan dari tumpukan dengan RtlAllocateHeap dan dibebaskan dengan RtlFreeHeap. Jika aplikasi asli ingin mencetak sesuatu ke layar, aplikasi tersebut harus menggunakan fungsi NtDisplayString, yang akan menghasilkan ke Layar Biru inisialisasi.

Aplikasi native tidak begitu saja kembali dari fungsi startup-nya seperti program Win32, karena tidak ada kode runtime untuk dikembalikan. Sebaliknya, mereka harus mengakhiri diri mereka sendiri dengan memanggil NtProcessTerminate.

Runtime NTDLL terdiri dari ratusan fungsi yang memungkinkan aplikasi asli untuk melakukan I/O file, berinteraksi dengan driver perangkat, dan melakukan komunikasi antarprosem. Sayangnya, seperti yang saya sebutkan sebelumnya, sebagian besar fungsi-fungsi ini tidak terdokumentasi.