Windows Debugging 202

Belki Windows internals i alip okumaya basladiniz ama takildiginiz noktalar oluyor. Zaten fark edeceksiniz ki hizlica okumak veya hizlica konularin üstünden geçmek pek mümkün degil. Ileriki bölümlerde bizi yine kitabin baslarina getirebilecek konular mevcut. Kitap genel terimlerden daha çok özel anlatimlara dogru ilerlemekte ve ondan bir sefer kitabi sindire sindire okumak aslinda sart. Ama unutmayin, bunu bir sefer yaptiktan sonra, ileride çikabilecek yeni edition lari okumak çok daha kolay olacaktir. Bu bloglar belki bölümleri okudugunuzdan sonra size kavram anlayisinizi artirmaya yardimci olacaklardir ve böylece ileriki bölümlerde daha fazla önemli detay hatirlamanizi saglayacaklardir.

Windows NT tasarlandiginda belli hedefleri yerine getirebilmesi bekleniliyordu. Windows o zamandan beri bu belli tasarim detaylarini sergilemektedir. Windows preemptive dir, yani örnegin bir threadi beklemeye alip, bu ilk thread ile alakasiz baska bir threadi çalistirdiktan sonra yine ilk threade çalisma hakki verebilir. Bu örnegin user mode/kernel mode olabilir. Kisaca farkli task lara zaman dilimleri vererek hepsini ayni anda yapabiliyormus gibi bit resm çizebiliriz. Ondan bu multitasking için bu önemlidir. Adi preempt dir çünkü çalisan taski her neyse bölmüs oluruz. Ikinci çok öenmli özellik Windows un reentrant olmasidir. Bu da kisaca preemption da böldügümüz ise tekrar girmek demekdir, re-entry gibi. Ayrica Windows farkli cpu ve donanimsal mimarilerde çalisabilmektedir. Windows bir network isletim sistemidir, yani is yükü dagilimi için client/server modelini uygulayabilir. Farkli hükümet ve endüstri standartlarini uygulayabilir ve daha önceki blogda sözü geçmis oldugu gibi Unicode dur. Bunun önemi Windows un Unicode olmasinin isletim sistemini var olan baska yapilar ile uyumlu yapiyor olmasidir.
Buradan Windows un tasarimsal en önemli özellikleri olusmaktadir: extensibility, varolan kodun hizlica degistirebiliniyor olmasi; portability, sistemin farkli donanimsal altyapilarda çalisiyor olmasi; reliability and robustness, isletim sisteminin kendisini hasarli kodlardan koruyabiliyor olmasi; compatibility, örnegin API lerin daha eski Windows sürümleri ile ve UNIX ve Netware gibi baska sistemler ile uyumlu olabilmesi ve performance olarak sistemin her altyapida ayni performansi sergileyebiliyor olmasi.

User mode/kernel mode dan 201 de de söz etmistik. Örnegin bir threadi user mode da baslatip, sonra bunu örnegin yeni bir proses yaratmasi için geçici kernel mode da çalistiriyor olabiliriz. Bu modelar adres bölgesi olarak ayriliyordu, ama cpu seviyesi olarak da yriliyordu. Bunu yapmamizin nedeni, user mode da bütün kaynaklara erisemiyor olmamiz. Bu bir güvenlik yapisi, ama kernelde de bütün kaynaklara erisim saglanmaktadir. Isletim sisteminin ana bölümü ve aygit sürücüler bu sadece kernel mode cpu seviyesinden/ring den erisebilir kernel mode adres bölümünü paylasirlar. Burada çalisan kod çok daha düsük engellerden dolayi teoride ciddi veri kirliligine neden olabilir. Bu yapiya monolithic isletim sistemi denilir. Windows object oriented tasarlanmaktadir, ancak çogu kod C de yazildigi için burada C in bu konudaki limitasyonlarina mahruz kalmaktadir. C de data type lari dynamically bind edemeyiz, class inheritance yoktur ve polymorphic fonksiyonlar da desteklenmez.
Multitasking demistik, ama multiprocessing açisindan Windows bir symetric multiprocessing (smp) isletim sistemidir. Yani her cpu çekirdeginde hem kernel mode hem user mode, hem user applicationlar ve hem de isletim sisteminin threadleri çalisabilir. Burada bazi çekirdekler sadece bazi islemler için rezerve edilmezler. Bununla beraber Windows un scalability özelligi gelir, yani scalability smp yi mümkün kilar. Ayrica Windows da yillar sonra geri gelen Hyperthreading ve büyük sunucu donanimlarin adminlerin node yapisi olarak tanidiklariNUMA non uniform memory access de desteklenir.

User mode tarafindan Kernel ile görüstügümüzde veya kernel mode da geçtigimizde aslinda gerçek kernel a geçmeyiz. Kernel in Executive adindaki üst yapisi ile çalisiriz. Kernel in kendisi bu çekirdegin asil alt yapisidir. Yalniz isletim sistemi sadece kernel mode dan olusmaz. User modeda da System process ler (idle process, session manager (smss.exe), logon process (winlogon.exe), local security authentication server lsass.exe ve service control manager gibi processler.), service process ler (örnegin print spooler) ve environment subsystem server processler çalisir (örnegin SUA, subsystem for Unix based applications). Diger user mode da çalisan kod sadece user applications olarak tanimlanir.

User mode da çalisan modüllerin hepsi Kernel e geçebilmek için ntdll.dll i kullanirlar. (Windows Debugging 201: API seviyesinin altinda da bizim örnek için aslinda NtCreateProcessEX fonksiyonu çalisir, yani asil isletim sisteminin Kernel kodunda çalisan fonksiyon budur. Bunlara native veya executive system services deriz. Ayrica direk API si olmayan sadece Kernel de manifeste edilmis fonksiyonlar da vardir, örnegin ExAllocatePoolWithTag. Bunlara da Kernel support functions/routines deriz. ) Iste bu sistem servisleri ve rutinleri de ntdll. dll üzerinden erisebiliriz. Bu erisebildigimiz kernel tarafina da Executive deriz. Yazdigimiz aygit sürücüleri de Executive e erisir. Örnegin bir IO aygit sürücüsünü kurdugumuzda bu kendisini IO manager a register eder ve sonra IO larda bizim sürücüde dahil edlir. IO manager Executive kod kisminda yer alir. Memory manager ve pkug and play manager larda Executive bölümlerde dir. Asil Kernel bu Executive ile HAL arasinda yer alir. Yani Windows un Kernel modeda çalisan ana bölümlerinden en üst katman Executive dir, Memory Management ve thread Management gibi roller üstlenir. Asil ama örnegin thread scheduling i yapan daha düsük seviyede çalisan Kernel dir. Kernel mode da aygit sürücüleri de çalisir. Daha alt seviyede HAL, hardware abstraction layer yapisi vardir ve bu kernel i farkli donanimlardan izole eder, yani bazi farklari kernel e kadar yukariya çikartmaz. Bunu kendisini hal.dll kütüphanesi olarak hizmete sunarak yapar. En nihayetinde kernel modeda windowing ve graphics system de çalisir.

Executive de çalisabilen aygit sürücülerimizi temel üç kategoriye ayiririz: bus (örnegin usb), funtion (asil aygit sürücüsü olarak anladigimiz sürücüler ) ve filter, yani diger sürücülerin arasinda ekstra islem yapilabilmesi için çalisan kernel sürücüleri. Genelde isletim sisteminin kendi bus sürücüleri kullanilir. Özel aygitlar için aygit sürücüleri çalisir ve antivirüsün sürücüsü örnegin bunlarin arasinda bir filter driver olarak taramasini yapar. Bu örnegin network veya disk tarafi ile ilgili sürücüler olabilir. Disk ile ilgili olarak IRP örnegi verile bilir ve Windows Debugging 106 daha detayli bilgi verilmistir.

Executive ve Kernel olarak çalisan kodlari ntoskrnl.exe altinda toplanir. Windows un direk sadece kernel mode da çalisan asil kernel aygit sürücüsü modülü de win32k.sys dir. Win32k.sys, csrss.exe (environment subsystem process), GDI ve Kernel32.dll gibi modüllerle Windows subsytem abstraksiyonunu olusturur. Bunun birinci görevi GDI yapilaridir. Genel kavram olarak görsel yapilar için çalisan optimizasyonlar diye biliriz. Kernel in Kernel diye adlandirdigimiz alt bölüm, yani cevizin içi gibi, en temel islemlerden sorumludur ve burasi ile Executive ile oldugu gibi girisimlerde bulunamayiz. Buradaki kodlarin fonksiyonlari Ke prefixi ile baslarlar. Asil Kernel in islevsel görevlerini kernel objeleri olarak adlandiririz. Buradaki en büyük fark kernelde cpu ile ilgili bilgilerin tutuldugu processor control region dir. Processor control blockda da isletim sistemi cpu yu nasil kullanacagina dair örnegin threadler ile ilgili bilgileri tutar. Bu bölümler tamamen asil kernel indir. Bu toplam region ve block u simdilik isletim sistemi ile cpu un çalisma çekirdegi olarak görebiliriz.

Bunlarin hepsi en temel mimari bilgileri ve terimleridir. Yukarida sözü geçen konular hakkinda daha detayli bilgiyi Windows Internals 5th ed. Chapter 2 ‘System Architecture’ altinda bulabilirsiniz:
https://technet.microsoft.com/en-us/sysinternals/bb963901

Eger kendinizi Windows mimarisinde gelistirmek istiyorsaniz veya isletim sisteminin bir referans kitabina ihtiyaciniz varsa bu kitabi incelemenizi öneririm.

https://www.dependencywalker.com
https://blogs.technet.com/b/platformtr/archive/2011/12/12/windows-debugging-201.aspx
https://blogs.technet.com/b/platformtr/archive/2009/06/10/windows-debugging-106.aspx

Basar Güner