最近正好在思考系統(tǒng)API設(shè)計(jì)中考量的一些問題，
【某網(wǎng)友討論到】
: 那地址是不是同一個(gè)地址呢。我現(xiàn)在的理解是這樣的，假設(shè)有巨大的真實(shí)內(nèi)存。windows首先將高2G的內(nèi)存自己占了，用作各種內(nèi)核對(duì)象。這2G內(nèi)存共享給每個(gè)進(jìn)程，但進(jìn)程不能直接訪問，只能通過windows給定的函數(shù)訪問。
: 然后每個(gè)進(jìn)程都給他2G內(nèi)存，進(jìn)程如果創(chuàng)建自己的對(duì)象就放到自己那2G內(nèi)存里面，如果要建立內(nèi)核對(duì)象就放到共享的那高2G里面去。
: 所以不同進(jìn)程如果可以訪問高2G內(nèi)存的話，任何進(jìn)程訪問到同一個(gè)高地址實(shí)際上都是訪問到同一個(gè)對(duì)象。但如果訪問低2G地址的話，不同進(jìn)程是對(duì)應(yīng)不同的對(duì)象的。
在不同的進(jìn)程中，詢問同一個(gè)內(nèi)核對(duì)象的實(shí)際地址（無論是線性地址還是物理地址），是無意義的：
首先，內(nèi)核對(duì)象只能由在內(nèi)核態(tài)下的例程才能直接訪問，在我們?nèi)粘５拇a中，所調(diào)用的Windows API，比如CreateFile, （注意調(diào)用剛開始時(shí)是處于用戶態(tài)下的），一般都會(huì)在ntdll.dll中找到對(duì)應(yīng)的內(nèi)核函數(shù)或例程，接著系統(tǒng)切換到內(nèi)核態(tài)，開始調(diào)用實(shí)際對(duì)應(yīng)的內(nèi)核函數(shù)(KiCreateFile)，這個(gè)時(shí)候才會(huì)去訪問內(nèi)核對(duì)象的實(shí)際地址，然后建立一個(gè)該內(nèi)核對(duì)象對(duì)應(yīng)當(dāng)前進(jìn)程的Handle，并把它返回給caller，同時(shí)切換回用戶態(tài)；因此，對(duì)于用戶態(tài)程序來說，只要且只能知道該內(nèi)核對(duì)象在當(dāng)前進(jìn)程中的對(duì)應(yīng)的Handle就可以對(duì)其進(jìn)行操作了；
其次，這樣的設(shè)計(jì)是出于對(duì)OS核心數(shù)據(jù)結(jié)構(gòu)（當(dāng)然包括我們正在討論的內(nèi)核對(duì)象）的保護(hù)；如果用戶態(tài)程序可以輕易的獲取內(nèi)核數(shù)據(jù)結(jié)構(gòu)的實(shí)際地址，那么對(duì)于整個(gè)OS的安全和穩(wěn)定顯然構(gòu)成很大的問題；一個(gè)用戶態(tài)的誤操作可以輕易的引起整個(gè)OS的崩潰，而有了這一層的保護(hù)，崩潰的只是當(dāng)前進(jìn)程而不是整個(gè)系統(tǒng)；
接著上面這點(diǎn)，也可以看出，內(nèi)核對(duì)象的如此設(shè)計(jì)達(dá)到了接納OS本身的平滑演進(jìn)的目的。從Windows 3.0到95/98，從NT到Win2k/XP，再到眼下的Vista/Win7，Windows操作系統(tǒng)本身發(fā)生了巨大的變化和進(jìn)步，采納了無數(shù)的新技術(shù)新方法，但是它基本的系統(tǒng)應(yīng)用編程接口，也就是我們所熟知的windows API，卻并沒有發(fā)生太大的改變，很多Win 3.0 這個(gè)16位OS時(shí)代的程序代碼只要當(dāng)初設(shè)計(jì)規(guī)范編碼規(guī)范，稍許修改就可以在最新版的OS上運(yùn)行如飛；是什么做到了這些？也就是所謂的極為重要的向后兼容性，我個(gè)人認(rèn)為，把操作系統(tǒng)的重要/主要功能抽象成內(nèi)核對(duì)象，并通過一套極為solid的API暴露出來，達(dá)成了這個(gè)目標(biāo)。
這是一種更高層次上的面向?qū)ο螅褜?shí)現(xiàn)的細(xì)節(jié)，把系統(tǒng)的復(fù)雜，簡單而優(yōu)雅的封裝了起來。你只要調(diào)用CreateFile去建個(gè)文件或管道或郵槽，不用擔(dān)心當(dāng)前OS是Windows 3.0還是Win7，獲得的Handle，你也不用去關(guān)心它以及它所指向的內(nèi)核對(duì)象是Windows 3.0的實(shí)現(xiàn)還是Win7的實(shí)現(xiàn)。
Windows上所有的精彩幾乎都是基于這套通過內(nèi)核對(duì)象概念抽象并暴露的API基礎(chǔ)之上，COM/OLE，這個(gè)二十年前震撼性的ABI和IPC范疇的技術(shù)規(guī)范，其中很多的設(shè)計(jì)思路也是植根于內(nèi)核對(duì)象的設(shè)計(jì)理念，如COM對(duì)象的引用計(jì)數(shù)和內(nèi)核對(duì)象引用計(jì)數(shù)，IUnknown和Windows Handle(前者是指向某個(gè)二進(jìn)制兼容的組件對(duì)象，后者引用或間接指向某個(gè)內(nèi)核對(duì)象，都是對(duì)于某個(gè)復(fù)雜概念的一致性抽象表述)，等等；
十年前的.net，本來是作為COM的升級(jí)版本推出，把COM/OLE的實(shí)現(xiàn)復(fù)雜性封裝在了虛擬機(jī)平臺(tái)CLR里面，而從這個(gè)虛擬機(jī)的開源實(shí)現(xiàn)SSCLI，我們可以看到大量的COM機(jī)制在.net的具體實(shí)現(xiàn)里面起了舉足輕重的作用。在這些VM中大量symbol有著COR的前綴或者后綴，COR指代什么？Common Object Runtime, 原來CLR/SSCLI的設(shè)計(jì)思路也是把OS通過虛擬機(jī)VM的形式，并通過common object向應(yīng)用程序暴露功能。
小結(jié)一下，
OS內(nèi)核對(duì)象API，三十年前系統(tǒng)級(jí)別的對(duì)象抽象；
COM/OLE，二十年前二進(jìn)制組件級(jí)別的對(duì)象抽象；
.net/CLR, 十年前虛擬機(jī)平臺(tái)級(jí)別的對(duì)象抽象；
寫到這里倒是引起了我其他的一些思考，軟件工業(yè)界一直以來對(duì)面向?qū)ο驩O是熱火朝天，特別是語言層面，從C++/Java/C#到Python/JScript，不一而足；
但是我們有沒有從根本性的設(shè)計(jì)理念上對(duì)面向?qū)ο螅旒{雅言了呢？
如果現(xiàn)在設(shè)計(jì)Windows這套API的任務(wù)放在大家面前，會(huì)采用內(nèi)核對(duì)象/Handle方案還是直接指向OS內(nèi)部數(shù)據(jù)結(jié)構(gòu)的方式來暴露功能？
從三十年前的這套API的設(shè)計(jì)中，我們真的可以學(xué)到很多。