第二節  TClass原子
在System.pas單元中，TClass是這樣定義的：
  TClass = class of TObject;
它的意思是說，TClass是TObject的類。因為TObject本身就是一個類，所以TClass就是所謂的類的類。
從概念上說，TClass是類的類型，即，類之類。但是，我們知道DELPHI的一個類，代表著一項VMT數據。因此，類之類可以認為是為VMT數據項定義的類型，其實，它就是一個指向VMT數據的指針類型！
在以前傳統的C++語言中，是不能定義類的類型的。對象一旦編譯就固定下來，類的結構信息已經轉化為絕對的機器代碼，在內存中將不存在完整的類信息。一些較高級的面向對象語言才可支持對類信息的動態訪問和調用，但往往需要一套復雜的內部解釋機制和較多的系統資源。而DELPHI的Object Pascal語言吸收了一些高級面向對象語言的優秀特征，又保留可將程序直接編譯成機器代碼的傳統優點，比較完美地解決了高級功能與程序效率的問題。
正是由于DELPHI在應用程序中保留了完整的類信息，才能提供諸如as和is等在運行時刻轉換和判別類的高級面向對象功能，而類的VMT數據在其中起了關鍵性的核心作用。有興趣的朋友可以讀一讀System單元的AsClass和IsClass兩個匯編過程，他們是as和is操作符的實現代碼，以加深對類和VMT數據的理解。
有了`類的類型，就可以將類作為變量來使用?？梢詫㈩惖淖兞坷斫鉃橐环N特殊的對象，你可以象訪問對象那樣訪問類變量的方法。例如：我們來看看下面的程序片段：
type
  TSampleClass = class of TSampleObject;
  TSampleObject = class( TObject )
  public
    constructor Create;
    destructor Destroy; override;
    class function GetSampleObjectCount:Integer;
    PRocedure GetObjectIndex:Integer;
  end;

var
  aSampleClass : TSampleClass;
  aClass : TClass;

在這段代碼中，我們定義了一個類TSampleObject及其相關的類類型TSampleClass，還包括兩個類變量aSampleClass和aClass。此外，我們還為TSampleObject類定義了構造函數、析構函數、一個類方法GetSampleObjectCount和一個對象方法GetObjectIndex。
首先，我們來理解一下類變量aSampleClass和aClass的含義。
顯然，你可以將TSampleObject和TObject當作常量值，并可將它們賦值給aClass變量，就好象將123常量值賦值給整數變量i一樣。所以，類類型、類和類變量的關系就是類型、常量和變量的關系，只不過是在類的這個層次上而不是對象層次上的關系。當然，直接將TObject賦值給aSampleClass是不合法的，因為aSampleClass是TObject派生類TSampleObject的類變量，而TObject并不包含與TSampleClass類型兼容的所有定義。相反，將TSampleObject賦值給aClass變量卻是合法的，因為TSampleObject是TObject的派生類，是和TClass類型兼容的。這與對象變量的賦值和類型匹配關系完全相似。
然后，我們再來看看什么是類方法。
所謂類方法，就是指在類的層次上調用的方法，如上面所定義的GetSampleObjectCount方法,它是用保留字class聲明的方法。類方法是不同于在對象層次上調用的對象方法的，對象方法已經為我們所熟悉，而類方法總是在訪問和控制所有類對象的共同特性和集中管理對象這一個層次上使用的。在TObject的定義中，我們可以發現大量的類方法，如ClassName、ClassInfo和NewInstance等等。其中，NewInstance還被定義為virtual的，即虛的類方法。這意味作你可以在派生的子類中重新編寫NewInstance的實現方法，以便用特殊的方式構造該類的對象實例。
在類方法中你也可使用self這一標識符，不過其所代表的含義與對象方法中的self是不同的。類方法中的self表示的是自身的類，即指向VMT的指針，而對象方法中的self表示的是對象本身，即指向對象數據空間的指針。雖然，類方法只能在類層次上使用，但你仍可通過一個對象去調用類方法。例如，可以通過語句aObject.ClassName調用對象TObject的類方法ClassName，因為對象指針所指向的對象數據空間中的頭4個字節又是指向類VMT的指針。相反，你不可能在類層次上調用對象方法，象TObject.Free的語句一定是非法的。
值得注意的是，構造函數是類方法，而析構函數是對象方法！
什么？構造函數是類方法，析構函數是對象方法！有沒有搞錯？
你看看，當你創建對象時分明使用的是類似于下面的語句：
    aObject := TObject.Create;
分明是調用類TObject的Create方法。而刪除對象時卻用的下面的語句：
    aObject.Destroy;
即使使用Free方法釋放對象，也是間接調用了對象的Destroy方法。
原因很簡單，在構造對象之前，對象還不存在，只存在類，創建對象只能用類方法。相反，刪除對象一定是刪除已經存在的對象，是對象被釋放，而不是類被釋放。
最后，順便討論一下虛構造函數的問題。
在傳統的C++語言中，可以實現虛析構函數，但實現虛構造函數卻是一個難題。因為，在傳統的C++語言中，沒有類的類型。全局對象的實例是在編譯時就存在于全局數據空間中，函數的局部對象也是編譯時就在堆?？臻g中映射的實例，即使是動態創建的對象，也是用new操作符按固定的類結構在堆空間中分配的實例，而構造函數只是一個對已產生的對象實例進行初始化的對象方法而已。傳統C++語言沒有真正的類方法，即使可以定義所謂靜態的基于類的方法，其最終也被實現為一種特殊的全局函數，更不用說虛擬的類方法，虛方法只能針對具體的對象實例有效。因此，傳統的C++語言認為，在具體的對象實例產生之前，卻要根據即將產生的對象構造對象本身，這是不可能的。的確不可能，因為這會在邏輯上產生自相矛盾的悖論！
然而，正是由于在DELPHI中有動態的類的類型信息，有真正虛擬的類方法，以及構造函數是基于類實現的等等這些關鍵概念，才可實現虛擬的構造函數。對象是由類產生的，對象就好象成長中的嬰兒，而類就是它的母親，嬰兒自己的確不知道自己將來會成為什么樣的人，可是母親們卻用各自的教育方法培養出不同的人，道理是相通的。
正是在TComponent類的定義中，構造函數Create被定義為虛擬的，才能使不同類型的控件實現各自的構造方法。這就是TClass創造的類之類概念的偉大，也是DELPHI的偉大。

......................................

第三章  WIN32的時空觀
    我的老父親看著地上玩玩具的小孫子，然后對我說：“這孩子和小時的你一樣，喜歡把東西拆開，看過究竟才罷手”。想想我小時侯，經常將玩具車、小鬧鐘、音樂盒，等等，拆得一塌糊涂，常常被母親訓斥。
    我第一次理解計算機的基本原理，與我拆過的音樂盒有關。那是在念高中時的一本漫畫書上，一位白胡子老頭在講解智能機的理論，一位留八字胡的叔叔在說計算機和音樂盒。他們說，計算機的中央處理器就是音樂盒中用來發音的那一排音樂簧片，計算機程序就是音樂盒中那個小圓筒上密布的凸點，小圓筒的轉動相當于中央處理器的指令指針的自然移動，而小圓筒上代表音樂的凸點控制音樂簧片振動發音相當于中央處理器執行程序的指令。音樂盒發出美妙的旋律，是按工匠早已刻在小圓筒上的音樂譜演奏的，計算機完成復雜的處理，是根據程序員預先編制好的程序實現的。上大學之后，我才知道那個白胡子老頭就是科學巨匠圖靈，他的有限自動機理論推動了整個信息革命的發展，而那個留八字胡的叔叔就是計算機之父馮.諾依曼，馮氏計算機體系結構至今仍然是計算機的主要體系機構。音樂盒沒白拆，母親可以寬心。
    有深入淺出的理解，才能有高深而又簡潔的創造。
    這一章我們將討論Windows的32位操作系統中與我們編程有關的基本概念，建立WIN32中正確的時空觀。希望閱讀完本章之后，我們能更加深入地理解程序、進程和線程，理解執行文件、動態連接庫和運行包的原理，看清全局數據、局部數據和參數在內存中的真相。


第一節  理解進程
    由于歷史的原因，Windows是起源于DOS。而在DOS時代，我們一直只有程序的概念，而沒有進程的概念。那時侯，只有操作系統的正規軍，如UNIX和VMS等等，才有進程的概念，而且多進程就意味著小型機、終端和多用戶，也意味著金錢。我絕大多數的時間只能使用相對廉價的微機和DOS系統，只是在學操作系統這門課程時才開始接觸進程和小型機。
    在Windows 3.X之后，Microsoft才在圖形界面的操作系統站住腳跟，而我也是在這時開始正式面對多任務和進程的概念。以前在DOS下，同一時間只能執行一個程序，而在Windows下同一時間可執行多個程序，這就是多任務。在DOS下運行一個程序的同時，不能執行相同的程序，而在Windows下，同一程序可以同時有兩個以上的副本在運行，每一個運行的程序副本就是一個進程。更確切地說，任何程序的一次運行就產生一個任務，而每個任務就是一個進程。
    當將程序和進程放到一起理解時，可以認為程序一詞說的是靜態的東西，一個典型的程序是由一個EXE文件或一個EXE文件加上若干DLL文件組成的靜態代碼和數據。而進程是程序的一次運行，是在內存中動態運行的代碼和動態變化的數據。當靜態的程序要求運行時，操作系統將為本次運行提供一定的內存空間，把靜態的程序代碼和數據調入這些內存空間，將程序的代碼和數據進行重定位映射之后，就在該空間內執行程序，這樣就產生了動態的進程。
    同一個程序同時運行著的兩個副本，意味著在系統內存中有兩個進程空間，只不過它們的程序功能是一樣的，但處于不同的動態變化的狀態之中。
    從進程運行的時間上來說，各進程是同時執行的，專業術語稱為并行執行或并發執行。但這主要是操作系統給我們的表面感覺，實際上各進程是分時執行的，也就是各進程輪流占用CPU的時間來執行進程的程序指令。對于一個CPU來說，同一時間只有一個進程的指令在執行。操作系統是調度進程運行的幕后操縱者，它不斷保存和切換各進程在CPU中執行的當前狀態，使得每一個被調度的進程都認為自己是完整和連續地運行著。由于進程分時調度的速度非?？?，所以給我們的感覺就是進程都是同時運行的。其實，真正意義上的同時運行只有在多CPU的硬件環境中才有。稍后在講述線程一節時，我們將發現，真正推動進程運轉的是線程，進程更重要的是提供了進程空間。
    從進程占據的空間上來說，各進程空間是相對獨立的，每一個進程在自己獨立的空間中運行。一個程序既包括代碼空間又包括數據空間，代碼和數據都要占據進程空間。Windows為每一進程所需的數據空間分配實際的內存，而對代碼空間一般都采用共享手段，將一個程序的一份代碼映射給該程序的多個進程。這意味著，如果一個程序有100K的代碼并需要100K的數據空間，也就是總共需要200K的進程空間，則第一次運行程序時操作系統將分配200K的進程空間，而運行程序的第二個進程時，操作系統只分配100K的數據空間，而代碼空間則共享前一個進程的空間。
    上面所說的是Windows操作系統中進程的基本時空觀，其實Windows的16位和32位操作系統在進程的時空觀上有很大的差異。
    從時間上來說，16位的Windows操作系統，如Windows 3.x等，進程管理是非常簡單的，它實際上只是一個多任務管理操作系統。而且，操作系統對任務的調度是被動的，如果一個任務不自己放棄對消息的處理，操作系統就必須等待。由于16位Windows系統在管理進程方面的缺陷，一個進程運行時，完全占有著CPU的資源。在那個年代，為了16位Windows可以有機會調度別的任務，微軟公司大力贊揚開發Windows應用程序的開發者是心胸寬闊的程序員，以使得他們樂意多編寫幾行恩賜給操作系統的代碼。相反，WIN32的操作系統，如Windows 95和NT等，才是具備了真正的多進程和多任務操作系統的能力。WIN32中的進程完全由操作系統調度，一旦進程運行的時間片結束，不管進程是否還在處理數據，操作系統將主動切換到下一進程。嚴格地說，16位的Windows操作系統不能算是完整的操作系統，而32位的WIN32操作系統才是真正意義上的操作系統。當然，微軟公司不會說WIN32彌補了16位Windows的缺陷，而是宣稱WIN32實現了一種稱為“搶占式多任務”的先進技術，這是商業手段。
    從空間上看，16位的Windows操作系統中的進程空間雖然相對獨立，但進程之間可已很容易地互相訪問對方的數據空間。因為，這些進程實際是在相同的物理空間中的不同的數據段而已，而且不當的地址操作很容易造成錯誤的空間讀寫，并使操作系統崩潰。然而，在WIN32操作系統中，各進程空間完全是獨立的。WIN32為每一個進程提供一個可達4G的虛擬的，并且是連續的地址空間。所謂連續的地址空間，是指每一個進程都擁有從$00000000到$FFFFFFFF的地址空間，而不是向16位Windows的分段式空間。在WIN32中，你完全不必擔心自己的讀寫操作會無意地影響到其他進程空間中的數據，也不用擔心別的進程會來騷擾你的工作。同時，WIN32為你的進程提供的連續的4G虛擬空間，是操作系統在硬件的支持下將物理內存映射給你的，你雖然擁有如此廣闊的虛擬空間，但系統決不會浪費一個字節的物理內存。

第二節  進程空間
    在我們用DELPHI編寫WIN32的應用程序時，很少去關心進程在運行時的內部世界。因為WIN32為我們的進程提供了4G的連續虛擬進程空間，可能目前世界上最龐大的應用程序也只用到了其中的部分空間。似乎進程空間是無限的，但4G的進程空間是虛擬的，而你機器的實際內存可能與此相差甚遠。雖然，進程擁有如此廣闊的空間，但有些復雜算法的程序還是會因為堆棧溢出而無法運行，特別是含有大量遞歸算法的程序。
    因此，深入地認識和了解這4G的進程空間的結構，以及它與物理內存的關系等等，將有助于我們更清楚地認識WIN32的時空世界，從而可在實際的開發工作中運用正確的世界觀和方法論解決各種難題。
    下面，我們將通過簡單的實驗，來了解WIN32的進程空間的內部世界。這可能需要一些對CUP寄存器和匯編語言的知識，但我盡量用簡單的語言來說明。
    當啟動DELPHI時，將自動產生一個Project1的項目，我們就拿它開刀。在Project1.dpr原程序的任意位置設一斷點，比如，就在begin一句處設一斷點。然后運行程序，當程序運行到斷點時會自動停下來。這時，我們就可以打開調試工具中的CPU窗口來觀察進程空間的內部結構了。
    當前的指令指針寄存器Eip是停在$0043E4B8，從程序指令所在地址的最高兩位16進制數都是零，可以看出當前的程序處在4G進程空間相當底端的地址位置，其占據$00000000到$FFFFFFFF的相當少的地址空間。
    在CPU窗口中的指令框中，你可以向上查看進程空間中的內容。當查看小于$00400000的空間內容時，你會發現小于$00400000的內容出現一串串的問號“????”，那是因為該地址空間還未映射到實際物理空間的緣故。如果在這時，你查看一下全局變量HInstance的16進制值就會發現它也是$00400000。雖然HInstance反映的是進程實例的句柄，其實，它就是程序被加載到內存中的起始地址值，在16位Windows中也是如此。因此，我們可以認為進程的程序是從$00400000開始加載的，也就是從4G虛擬空間中的4M以后的空間開始是程序加載的空間。
    從$00400000往后，到$0044D000之前，主要是程序代碼和全局數據的地址空間。在CPU窗口中的堆?？蛑?，可以查看到當前堆棧的地址。同樣，你會發現當前堆棧的地址空間是從$0067B000到$00680000的，長度為$5000。其實，進程最小的堆?？臻g大小就是$5000，它是根據編譯DELPHI程序時在ProjectOptions中Linker頁中設置的Min stack size值，加上$1000而得到的。堆棧是由高端地址向底端增長的，當程序運行的堆棧不夠時，系統將自動向地端地址方向增加堆?？臻g的大小，這一過程將把更多的實際內存映射到進程空間?？稍诰幾gDELPHI程序時，通過設置ProjectOptions中Linker頁中Max stack size的值，控制可增加的最大堆?？臻g。特別是在含有深層次的子程序調用關系或運用遞歸算法的程序中，一定要合理地設置Max stack size的值。因為，調用子程序是需要耗用堆?？臻g，而堆棧耗盡之后，系統就會拋出“Stack overflow”的錯誤。
    似乎，從堆?？臻g之后的進程空間就應該是自由的空間了吧。其實不然，WIN32的有關資料說，$80000000之后的2G空間是系統使用的空間?？磥?，進程能夠真正擁有的只有2G空間。其實，進程能真正擁有的空間連2G都不夠，因為從$00000000到$00400000的這4M空間也是禁區。
    但不管怎樣，我們的進程可以使用的地址還是非常廣闊的。特別是堆?？臻g之后到$80000000之間，是進程空間的主戰場。進程從系統分配的內存空間將被映射到這塊空間，進程加載的動態連接庫將被映射到這塊空間，新建線程的線程堆?？臻g也將映射到這塊空間，幾乎所有涉及分配內存的操作都將映射到這塊空間。請注意，這里所說的映射，意味著實際內存與這塊虛擬空間的對應，沒有映射為實際內存的進程空間是無法使用的，就象調試時CPU窗口指令框中的那一串串的“????”。
................

謝謝閱讀！