Yerel Uygulamaların İçinde

Mark Russinovich Yayın Tarihi: 1 Kasım 2006

Giriş

NT'nin mimarisi hakkında biraz bilginiz varsa, Win32 uygulamalarının kullandığı API'nin "gerçek" NT API olmadığını muhtemelen biliyorsunuzdur. POSIX, OS/2 ve Win32 içeren NT'nin işletim ortamları kendi API'leri aracılığıyla istemci uygulamalarıyla konuşur, ancak NT "yerel" API'sini kullanarak NT ile konuşur. Yerel API çoğunlukla belgelenmemiştir ve Windows NT Device Driver Kit'te açıklanan 250 işlevin yalnızca 25'i kadardır.

Ancak çoğu kişinin bilmediği şey, NT'de işletim ortamlarının herhangi birinin istemcisi olmayan "yerel" uygulamaların mevcut olmasıdır. Bu programlar yerel NT API'sini konuşur ve Win32 gibi işletim ortamı API'lerini kullanamaz. Bu tür programlara neden ihtiyaç duyulabilir" Win32 alt sistemi başlatılmadan önce çalışması gereken tüm programlar (oturum açma kutusu göründüğü sırada) yerel bir uygulama olmalıdır. Yerel bir uygulamanın en belirgin örneği, başlatma sırasındaki Mavi Ekran'da chkdsk'yi çalıştıran "autochk" programıdır (ekranda "." karakterlerini yazdıran programdır). Doğal olarak, CSRSS.EXE (Client-Server Çalışma Zamanı Alt Sistemi) Win32 işletim ortamı sunucusu da yerel bir uygulama olmalıdır.

Bu makalede yerel uygulamaların nasıl oluşturulduğu ve nasıl çalıştıkları açıklanmaktadır.

Autochk Nasıl Yürütülür?

Autochk, NT'nin önyükleme ve sistem başlangıcı sürücülerinin yüklendiği zaman ile sayfalamanın etkinleştirildiği zaman arasında çalışır. Bu noktada, önyükleme sırasında Oturum Yöneticisi (smss.exe) NT'nin kullanıcı modu ortamını sıfırdan alıyor ve başka hiçbir program etkin değil. HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute değeri, MULTI_SZ, Oturum Yöneticisi tarafından yürütülen programların adlarını ve bağımsız değişkenlerini içerir ve Autochk'in belirtildiği yerdir. "Autochk" öğesine argüman olarak "*" geçirildiği durumlarda, bu değere baktığınızda genellikle şunları görürsünüz:

Autocheck Autochk *

Oturum Yöneticisi , bu değerde <listelenen yürütülebilir dosyalar için winnt>\system32 dizinine bakar. Autochk çalıştırıldığında açık dosya yoktur, bu nedenle Autochk önyükleme sürücüsü de dahil olmak üzere herhangi bir birimi ham modda açabilir ve disk üzerindeki veri yapılarını işleyebilir. Bu, daha sonraki bir noktada mümkün olmayacaktır.

Yerel Uygulamalar Oluşturma

Microsoft bunu belgelemiyor, ancak NT DDK Derleme yardımcı programı yerel uygulamaların nasıl yapılacağını biliyor (ve büyük olasılıkla Autochk'ı derlemek için kullanılıyordu). Uygulamayı tanımlayan bir SOURCES dosyasında, cihaz sürücüleri için yapılanla aynı bilgileri belirtirsiniz. Ancak, Build'a bir sürücü istediğinizi belirtmek yerine SOURCES dosyasında aşağıdaki gibi yerel bir uygulama istediğinizi söylersiniz:

TARGETTYPE=PROGRAM

Build aracı, kendisini yönlendirmek için \ddk\inc\makefile.def adlı standart bir makefile dosyası kullanır; bu dosya, yerel uygulamaları derlerken nt.lib adlı bir çalışma zamanı kitaplığını arar. Ne yazık ki, Microsoft bu dosyayı DDK ile göndermez (Sunucu 2003 DDK'sına dahildir, ancak bu sürümle bağlantı yaparsanız yerel uygulamanızın XP'de veya Windows 2000'de çalışmayacağından şüpheleniyorum). Ancak, Visual C++'ın çalışma zamanı kitaplığı msvcrt.lib'i belirterek nt.lib seçimini geçersiz kılan makefile.def dosyasına bir satır ekleyerek bu soruna geçici bir çözüm bulabilirsiniz

Build'i DDK'nin "Checked Build" ortamında çalıştırırsanız, %BASEDIR%\lib%CPU%\Checked altında tam hata ayıklama bilgilerine sahip yerel bir uygulama üretir (ör. c:\ddk\lib\i386\checked\native.exe); "Free Build" ortamında çalıştırırsanız, programın sürüm derlemesi %BASEDIR%\lib%CPU%\Free altında oluşturulur. Bunlar, derleme işleminin cihaz sürücüsü imajlarını yerleştirdiği aynı yerlerdir.

Yerel uygulamaların ".exe" dosya uzantıları vardır, ancak bunları Win32 .exegibi çalıştıramazsınız. Denerseniz şu iletiyi alırsınız:

Uygulama Windows NT modunda çalıştırılamaz.

Yerel Uygulamanın İçinde

Winmain veya main yerine yerel uygulamaların giriş noktası NtProcessStartup'tır. Ayrıca, diğer Win32 giriş noktalarından farklı olarak yerel uygulamalar, komut satırı bağımsız değişkenlerini bulmak üzere kendilerine tek parametre olarak geçirilen bir veri yapısının içindeki bilgilere erişmek zorundadır.

Yerel bir uygulamanın çalışma zamanı ortamının çoğunluğu NT'nin yerel API dışarı aktarma kitaplığı olan NTDLL.DLL tarafından sağlanır. Yerel uygulamalar, bir NTDLL işlevi olan RtlCreateHeap kullanarak depolamanın ayrılacağı kendi yığınlarını oluşturmalıdır. Bellek RtlAllocateHeap ile bir yığından ayrılır ve RtlFreeHeap ile serbest bırakılır. Yerel bir uygulama ekrana bir şey yazdırmak isterse, Mavi Ekran'ın başlatılmasına neden olacak NtDisplayString işlevini kullanmalıdır.

Yerel uygulamalar, Win32 programlarında olduğu gibi, başlatma işlevlerinden öylece geri dönmez; çünkü geri dönülecek bir çalışma zamanı kodu yoktur. Bunun yerine , NtProcessTerminate'i çağırarak kendilerini sonlandırmaları gerekir.

NTDLL çalışma zamanı, yerel uygulamaların dosya G/Ç gerçekleştirmesine, cihaz sürücüleriyle etkileşim kurmasına ve işlemler arası iletişimler gerçekleştirmesine olanak sağlayan yüzlerce işlevden oluşur. Ne yazık ki, daha önce de belirttiğim gibi, bu işlevlerin büyük çoğunluğu belgelenmemiştir.