Windows NT 核心基本結構

轉自：http://spinlock.blog.51cto.com/607469/174696

作者：kevx

 

儘管大部分人每天在Windows系統上工作學習娛樂，但是對於其核心結構很多人仍然是不瞭解的。一方面是由於其核心原始碼不開源，另一方面則是由於相關資料的奇缺。我大二基本上花了一學期來學習和探究NT核心。雖然不敢說自己對其有很深入的瞭解，但至少其基本結構還算是清楚的。但是我畢竟才學有限，肯定會有不完善的地方，還請各位不吝賜教。

目前微軟所有的主流作業系統均是基於NT核心，比如：
Windows 2000/XP/Server 2003(基於NT5)
Windows Vista (基於NT6)Windows 7(基於NT6.1, 我沒裝過Win7，不過據說是這樣的)

儘管很多人責備Windows在一些方面存在很多問題，但是這並不是核心的錯，總的來說，NT的是一個成熟穩定且先進的核心，我認為在今後相當長的一段時期內，NT核心仍將是主流，且不會有很大變化（當然，局部的升級是完全毫無疑問的）
微軟早期希望把NT做成一個純微核心結構，關於微核心和單一核心的區別，各位如有不清楚的，可以去網上搜尋一下。後來為了提高圖形子系統的效能，避免大量的核心態和使用者態切換，微軟便將其移入核心之中，使其成為核心一部分（類似的還有後來的DirectX技術）。由此可見，NT並不是一個完全的微核心，它也具有單一核心的某些特徵。

NT核心具有以下幾個特徵（摘自Undocumented Windows NT）Portability （可移植性）
如你所知，Windows NT 可以運行在多種平台上，即 Intel、MIPS、Power PC 和 DEC Alpha。眾多廠商都為 Windows NT 的可移植性做出了貢獻。 其中最為重要的因素可能是其實現所使用的語言。Windows NT 大部分是用 C 語言編寫的，也有一部分用的是 C++。 平台相關的組合語言只在必需的地方才用到。Windows NT 團隊還將作業系統中硬體相關的部分與其它部分隔離開，單獨放進了 HAL.DLL。 如此一來，Windows NT 中與硬體無關的部分的代碼就可以用 C 之類的進階語言來編寫，也因此可以很容易地移植到各種平台。Extensibility（可擴充性）
Windows NT 具有很高的可擴充性，但因為缺少文檔，其可擴充的特性卻極少得到發掘。未公開的特性的名單中，子系統首當其衝。子系統在作業系統中提供了多種作業系統介面。只需添加新的子系統程式就可以為 Windows NT 擴充新的作業系統介面，但是對於公開添加新子系統過程的要求微軟卻一直打馬虎眼。

Windows NT 的核心是高可擴充的，因為可以將核心模組作為驅動程式動態載入。對於 Windows NT，微軟提供了足夠的文檔來編寫硬體裝置驅動——即硬碟驅動、網卡驅動、磁帶機驅動等等。在 Windows NT 下還可以編寫不控制裝置的驅動程式。甚至連檔案系統也是作為驅動程式載入的。
Windows NT 的可擴充性的另一個例子就是系統調用介面的實現。 開發人員要修改作業系統行為，一般都需要鉤掛或添加系統調用。 Windows NT 的Team Dev實際了良好的系統調用介面以方便鉤掛和添加系統調用。但是微軟還是沒有公開這些機制。

Compatibility（相容性）
長久以來，向下相容性都是 Intel 處理器和微軟作業系統的一大特徵，也是這兩位巨人成功的關鍵。Windows NT 必須能運行 DOS、Win16 和 OS/2 的程式。相容性是 Windows NT Team Dev使用子系統概念的另一個原因。除二進位相容之外（執行不同格式的可執行檔），Windows NT 還為符合 POSIX 的程式提供了原始碼級的相容。增強相容性的其他方面還表現在除自己本身的 NTFS 外，Windows NT 支援其它的檔案系統，如 DOS 的 FAT 和 OS/2 的 HPFS。

Maintainability（可維護性）
Windows NT 的代碼量很大，維護著些代碼的工作量也相當大。NT 的Team Dev通過使用物件導向的設計實現了高可維護性。再有，將作業系統的功能分成各個層也提高了可維護性。最上面的一層，也就是使用者見到的作業系統層面，是子系統層。子系統提供系統調用介面來為外界提供API。在系統調用介面層之下的是 NT 的 executive，executive 又建立在核心之上，而核心又依賴於硬體抽象層（HAL），硬體抽象層與硬體直接通訊。
NT 的Team Dev所選的程式設計語言也與 Windows NT 的可維護性有關。正如我們前面提到的，整個作業系統都是用 C 和 C++ 來編寫的，只有極少數不用不行的地方用了組合語言。

Security（安全性）
Windows NT 是一個安全的作業系統，是因為它有以下幾點特徵：使用者在使用系統之前必須先登陸。 系統中的資源都被視為對象，而每一個對象都相應由一個安全性描述元。安全性描述元有一個安全清單來指示那些使用者可以訪問該對象。

儘管有這些，要是沒有一個安全的檔案系統，作業系統也不能說是安全的。 DOS 時的 FAT 檔案系統沒有預見到任何的安全問題，其作為一個單使用者的系統，也不用防範安全問題。

為了克服此缺陷，Windows NT 團隊推出了一種新的檔案系統，這種檔案系統基於 OS/2 的檔案系統 HPFS。這種新的 Windows NT 的自有檔案系統叫 NTFS。它支援存取控制，使用者可以為 NTFS 下建立的檔案或目錄指定存取權限，NTFS 只允許有存取權限的進程訪問該檔案或目錄。

Multiprocessing（多進程）
Windows NT 支援對稱式多處理，Windows NT 的工作站版本可以支援兩個處理器，伺服器版可以支援到4個。為支援多處理，作業系統需要特殊的同步機制。在單一處理器系統中，通過禁用中斷，臨界區中的代碼執行時不會被打斷。這對於維護核心資料結構的完整性來說是必需的。在多處理器環境下，就不可能在所有的處理器上都禁用中斷。在多處理環境中，Windows NT 使用自旋鎖來保護核心資料結構。

註：多處理可分為對稱的和非對稱的。在非對稱式多處理中，有一個處理器為主處理器，其它的處理器都為從處理器。只有主處理器運行在核心模式，其它從處理器都只運行在使用者線程。只要運行在使用者線程的從處理器一調用系統服務，主處理器就接管此線程並執行所需的核心服務。發送器，一個核心程式，之運行在主處理器上。因此，主處理扮演者調度員的角色，將使用者模式線程指派給從處理器。很自然，與所有處理器都可在核心或使用者模式啟動並執行對稱式多處理相比，主處理器負擔很重，系統不均衡。

International Language Support（國際化語言支援）
如今眾多的 PC 使用者都使用英語之外的其它語言。與這些使用者能很好互動的關鍵就是使作業系統能支援使用者們的語言。Windows NT 通過使用 Unicode 標準的字元集實現了這一目標。Unicode 標準規定了一個16位的字元集，而ASCII 使用的是8位字元集。 Unicode 的前256個字元的編碼與 ASCII 的相同。這就為非拉丁語的語言留出了充足的空間。Win32 API 能接受 Unicode 和 ASCII 兩種字元集，而 Windows NT 的核心則只能使用 Unicode。儘管應用程式程式員可以不去瞭解 Unicode，但驅動程式的開發人員必須熟悉 Unicode，因為核心介面函數只接受 Unicode 字串而且驅動的進入點都用的是 Unicode。

Windows NT 從 MACH 作業系統那裡借用了核心體系，MACH 作業系統是在卡耐基梅隆大學開發的。MACH 作業系統的基本理念就是通過將複雜的作業系統功能交給使用者級進程而將核心減至最小。這種客戶機-伺服器的作業系統體系還有另外一個目的：允許在同一作業系統上使用多種 APIs。通過在伺服器處理序中實現 APIs 就可以做到。

MACH 作業系統的核心提供了非常簡單的一組介面函數。伺服器處理序使用這組介面函數實現出某種 API 來提供一組更複雜的介面函數。Windows NT 從 MACH 那裡借用了這個理念。Windows NT 中的伺服器處理序被稱作子系統。模組化和結構化的程式設計都是優秀軟體管理的原則，NT 選擇使用客戶機-伺服器的體繫結構顯示了它對這種原則的服從。Windows NT 本可以將所需的 APIs 在核心實現，也可以在核心上加上不同的層來實現不同的 APIs。出於維護性和擴充性的目的，NT 團隊選擇了子系統的辦法。

Windows NT 中有兩種子系統： integral subsystems 和 environment subsystems。Integral subsystems，如安全管理子系統，完成基本的作業系統任務。 Environment subsystems 則使得一台 Windows NT 機器能使用不同種類的 APIs。Windows NT 的子系統能支援以下的 APIs：

Win32 子系統。Win32 子系統提供 Win32 API。使用 Win32 API 的應用程式可以運行在微軟 提供的所有平台上—

WOW 子系統。Windows on Windows (WOW) 子系統提供了對 16-bit Windows 應用程式的相容，使得 Win16 的應用程式可以在 Windows NT 上運行。只要沒有使用 Windows NT 不支援的未公開函數，這些應用程式都可以運行。

NTVDM 子系統。NT Virtual DOS Machine (NTVDM) 提供了一個基於文本的環境，DOS 程式可以在這個環境中運行。

OS/2 子系統。OS/2 子系統能運行 OS/2 應用程式。WOW、NTVDM 和 OS/2 都只能用在 Intel 平台上，因為他們都對應用程式提供二進位相容性。而用於一種處理器的可執行檔或二進位檔案就不能用在另一種處理器上，因為處理器間的機器指令格式不同。

POSIX 子系統。POSIX 子系統提供符合 POSIX 1003.1 標準的 API。

應用程式並不知道所調用的 API 是由相應的子系統處理的。這種隱藏是通過每種子系統各自的用戶端 DLL 來實現的。這種 DLL 將 API 呼叫轉換為本地程序呼叫（local procedure call，LPC）。本地程序呼叫類似於連網的 UNIX 上的遠端程序呼叫（RPC）。使用 RPC，客戶應用程式可以調用運行在網路上另一台機器上的伺服器處理序。 LPC 對運行在同一台電腦上的客戶機與伺服器進行了最佳化。

NT核心主要包含以下幾個重要檔案：
Ntoskrnl.exe（或者Ntkrnlpa.exe）  
HAL.Dll
NTDll.Dll
Win32k.SysNT核心的核心是NT EXECUTIVE。對應的檔案是Ntoskrnl.exe。如果是機器是多處理器的，則是Ntkrnlpa.exe。非常可笑的是，這個檔案可以直接刪除，其後果就是重啟後Windows無法啟動，甚至連捲軸都看不到。該檔案只有2MB左右的大小，但可謂是麻雀雖小五髒俱全，它作為整個Windows中最核心的部分，向外界提供了複雜的介面。與之相輔相成的是HAL.Dll檔案，即Hardware Abstraction Layer 硬體抽象層 。它直接與機器的硬體打交道，將硬體的差異對其之上的層隱藏起來。Windows NT 是一個有高可移植性的作業系統，運行在多種平台上。HAL.DLL 包含的代碼向核心的其它部分隱藏了處理器和機器相關的細節。因此平台之間只有 HAL.DLL 不同，剩下的使用 HAL 介面的核心代碼都有很高的可移植性。NTDll.Dll模組。匯出了大部分的Native API函數，提供了由使用者態至核心態的切換的功能。做過Windows平台開發的人都知道，Windows API主要由Kernel32.Dll, User32.Dll, GDI32.Dll構成。其實對WindowsAPI的調用最終會被轉接到NTDll。即所謂Native API，命名上基本上就是在原API前面加上Nt或者Zw（比如CreateFile就變成了NtCreateFile）。而Kernel32.Dll, User32.Dll, GDI32.Dll三個檔案則組成了Win32子系統，它們本身不實現API，它匯出的函數被稱為stub 函數（儘管名稱上看起來很迷惑人）

Win32K.sys模組。實現了Windows的圖形處理部分。USER32 和 GDI32 使用系統調用介面來調用 WIN32K.SYS 中的服務。由於其工作與核心態，所以具有很高的效能，這也成就了Windows系統的強大的圖形處理能力。