Delphi的原子世界

时间：2019-07-09 15:32:02

关键字： delphi Windows

[导读]DELPHI的原子世界在使用Delphi开发软件的过程中，我们就像草原上一群快乐牛羊，无忧无虑地享受着Object Pascal语言为我们带来的阳光和各种VCL控件提供的丰富的水草。抬头望望无边无际

DELPHI的原子世界

在使用Delphi开发软件的过程中，我们就像草原上一群快乐牛羊，无忧无虑地享受着Object Pascal语言为我们带来的阳光和各种VCL控件提供的丰富的水草。抬头望望无边无际蔚蓝的天空，低头品尝大地上茂密的青草，谁会去想宇宙有多大，比分子和原子更小的东西是什么？那是哲学家的事。而哲学家此时正坐在高高的山顶上，仰望宇宙星云变换，凝视地上小虫的爬行，蓦然回头，对我们这群吃草的牛羊点头微笑。随手扯起一根小草，轻轻地含在嘴里，闭上眼睛细细品尝，不知道这根青草在哲学家的嘴里是什么味道？只是，他的脸上一直带着满意的微笑。

认识和了解DELPHI微观的原子世界，可以使我们彻底理解DELPHI的宏观应用程序结构，从而在更广阔的思想空间中开发我们的软件。这就好像，牛顿发现了宏观物体的运动，却因为搞不清物体为什么会这样运动而苦恼，相反，爱因斯坦却在基本粒子规律和宏观物体运动之间体验着相对论的快乐生活！

第一节 TObject原子

TObject是什么？

是Object Pascal语言体系结构的基本核心，也是各种VCL控件的起源。我们可以认为，TObject是构成DELPHI应用程序的原子之一，当然，他们又是由基本Pascal语法元素等更细微的粒子构成。

说TObject是DELPHI程序的原子，是因为TObject是DELPHI编译器内部支持的。所有的对象类都是从TObject派生的，即使你并未指定TObject为祖先类。TObject被定义在System单元，它是系统的一部分。在System.pas单元的开头，有这样的注释文本：

{ Predefined constants, types, procedures, }

{ and functions (sUCh as True, Integer, or }

{ Writeln) do not have actual declarations.}

{ Instead they are built into the compiler }

{ and are treated as if they were declared }

{ at the beginning of the System unit. }

它的意思说，这一单元包含预定义的常量、类型、过程和函数（诸如：Ture、Integer或Writeln），它们并没有实际的声明，而是编译器内置的，并在编译的开始就被认为是已经声明的定义。你可以将Classes.pas或Windows.pas等其他源程序文件加入你的项目文件中进行编译和调试其源代码，但你绝对无法将System.pas源程序文件加入到你的项目文件中进行编译！DELPHI将报告重复定义System的编译错误！

因此，TObject是编译器内部提供的定义，对于我们使用DELPHI开发程序的人来说，TObject是原子性的东西。

TObject在System单元中的定义是这样的：

TObject = class

constructor Create;

procedure Free;

class function InitInstance(Instance: Pointer): TObject;

procedure CleanupInstance;

function ClassType: TClass;

class function ClassName: ShortString;

class function ClassNameIs(const Name: string): Boolean;

class function ClassParent: TClass;

class function ClassInfo: Pointer;

class function InstanceSize: Longint;

class function InheritsFrom(AClass: TClass): Boolean;

class function MethodAddress(const Name: ShortString): Pointer;

class function MethodName(Address: Pointer): ShortString;

function FieldAddress(const Name: ShortString): Pointer;

function GetInterface(const IID: TGUID; out Obj): Boolean;

class function GetInterfaceEntry(const IID: TGUID): PInterfaceEntry;

class function GetInterfaceTable: PInterfaceTable;

function SafeCallException(ExceptObject: TObject;

ExceptAddr: Pointer): HResult; virtual;

procedure AfterConstruction; virtual;

procedure BeforeDestruction; virtual;

procedure Dispatch(var Message); virtual;

procedure DefaultHandler(var Message); virtual;

class function NewInstance: TObject; virtual;

procedure FreeInstance; virtual;

destructor Destroy; virtual;

end;

下面，我们将逐步敲开TObject原子的大门，看看里面到底是什么结构。

我们知道，TObject是所有对象的基本类，那么，一个对象到底是什么？

DELPHI中的任何对象都是一个指针，这个指针指明该对象在内存中所占据的一块空间！虽然，对象是一个指针，可是我们引用对象的成员时却不用写成这样的代码MyObject^.GetName，而只能写成MyObject.GetName，这是Object Pascal语言扩充的语法，是由编译器支持的。使用C++ Builder的朋友就很清楚对象与指针的关系，因为在C++ Builder的对象都要定义为指针。对象指针指向的地方就是对象存储数据的对象空间，我们来分析一下对象指针指向的内存空间的数据结构。

对象空间的头4个字节是指向该对象类的虚方法地址表（VMT – Vritual Method Table）。接下来的空间就是存储对象本身成员数据的空间，并按从该对象最原始祖先类的数据成员到该对象类的数据成员的总顺序，和每一级类中数据成员的定义顺序存储。

类的虚方法地址表（VMT）保存从该类的原始祖先类派生到该类的所有类的虚方法的过程地址。类的虚方法，就是用保留字vritual声明的方法，虚方法是实现对象多态性的基本机制。虽然，用保留字dynamic声明的动态方法也可实现对象的多态性，但这样的方法不保存在虚方法地址表（VMT）中，它只是Object Pascal提供的另一种可节约类存储空间的多态实现机制，但却是以牺牲调用速度为代价的。

即使，我们自己并未定义任何类的虚方法，但该类的对象仍然存在指向虚方法地址表的指针，只是地址项的长度为零。可是，在TObject中定义的那些虚方法，如Destroy、FreeInstance等等，又存储在什么地方呢？原来，他们的方法地址存储在相对VMT指针负方向偏移的空间中。其实，在VMT表的负方向偏移76个字节的数据空间是对象类的系统数据结构，这些数据结构是与编译器相关的，并且在将来的DELPHI版本中有可能被改变。

因此，你可以认为，VMT是一个从负偏移地址空间开始的数据结构，负偏移数据区是VMT的系统数据区，VMT的正偏移数据是用户数据区（自定义的虚方法地址表）。TObject中定义的有关类信息或对象运行时刻信息的函数和过程，一般都与VMT的系统数据有关。

一个VMT数据就代表一个类，其实VMT就是类！在Object Pascal中我们用TObject、TComponent等等标识符表示类，它们在DELPHI的内部实现为各自的VMT数据。而用class of保留字定义的类的类型，实际就是指向相关VMT数据的指针。

对我们的应用程序来说，VMT数据是静态的数据，当编译器编译完成我们的应用程序之后，这些数据信息已经确定并已初始化。我们编写的程序语句可访问VMT相关的信息，获得诸如对象的尺寸、类名或运行时刻的属性资料等等信息，或者调用虚方法或读取方法的名称与地址等等操作。

当一个对象产生时，系统会为该对象分配一块内存空间，并将该对象与相关的类联系起来，于是，在为对象分配的数据空间中的头4个字节，就成为指向类VMT数据的指针。

我们再来看看对象是怎样诞生和灭亡的。看着我三岁的儿子在草地上活蹦乱跳，正是由于亲眼目睹过生命的诞生过程，我才能真真体会到生命的意义和伟大。也只有那些经历过死别的人，才会更加理解和珍惜生命。那么，就让我们理解一下对象的产生和消亡的过程吧！

我们都知道，用下面的语句可以构造一个最简单对象：

AnObject := TObject.Create;

编译器将其编译实现为：

用TObject对应的VMT为依据，调用TObject的Create构造函数。而在Create构造函数调用了系统的ClassCreate过程，系统的ClassCreate过程又通过存储在类VMT调用NewInstance虚方法。调用NewInstance方法的目的是要建立对象的实例空间，因为我们没有重载该方法，所以，它就是TObject类的NewInstance。TObjec类的NewInstance方法将根据编译器在VMT表中初始化的对象实例尺寸（InstanceSize），调用GetMem过程为该对象分配内存，然后调用InitInstance方法将分配的空间初始化。InitInstance方法首先将对象空间的头4个字节初始化为指向对象类对应VMT的指针，然后将其余的空间清零。建立对象实例之后，还调用了一个虚方法AfterConstruction。最后，将对象实例数据的地址指针保存到AnObject变量中，这样，AnObject对象就诞生了。

同样，用下面的语句可以消灭一个对象：

AnObject.Destroy;

TObject的析构函数Destroy被声明为虚方法，它也是系统固有的虚方法之一。Destory方法首先调用了BeforeDestruction虚方法，然后调用系统的ClassDestroy过程。ClassDestory过程又通过类VMT调用FreeInstance虚方法，由FreeInstance方法调用FreeMem过程释放对象的内存空间。就这样，一个对象就在系统中消失。

对象的析构过程比对象的构造过程简单，就好像生命的诞生是一个漫长的孕育过程，而死亡却相对的短暂，这似乎是一种必然的规律。

在对象的构造和析构过程中，调用了NewInstance和FreeInstance两个虚函数，来创建和释放对象实例的内存空间。之所以将这两个函数声明为虚函数，是为了能让用户在编写需要用户自己管理内存的特殊对象类时（如在一些特殊的工业控制程序中），有扩展的空间。

而将AfterConstruction和BeforeDestruction声明为虚函数，也是为了将来派生的类在产生对象之后，有机会让新诞生的对象呼吸第一口新鲜空气，而在对象消亡之前可以允许对象完成善后事宜，这都是合情合理的事。其实，TForm对象和TDataModule对象的OnCreate事件和OnDestroy事件，就是在TForm和TDataModule重载的这两个虚函数过程分别触发的。

此外，TObjec还提供了一个Free方法，它不是虚方法，它是为了那些搞不清对象是否为空（nil）的情况下能安全释放对象而专门提供的。其实，搞不清对象是否为空，本身就有程序逻辑不清晰的问题。不过，任何人都不是完美的，都可能犯错，使用Free能避免偶然的错误也是件好事。然而，编写正确的程序不能一味依靠这样的解决方法，还是应该以保证程序的逻辑正确性为编程的第一目标！

有兴趣的朋友可以读一读System单元的原代码，其中，大量的代码是用汇编语言书写的。细心的朋友可以发现，TObject的构造函数Create和析构函数Destory竟然没有写任何代码，其实，在调试状态下通过Debug的CPU窗口，可清楚地反映出Create和Destory的汇编代码。因为，缔造DELPHI的大师门不想将过多复杂的东西提供给用户，他们希望用户在简单的概念上编写应用程序，将复杂的工作隐藏在系统的内部由他们承担。所以，在发布System.pas单元时特别将这两个函数的代码去掉，让用户认为TObject是万物之源，用户派生的类完全从虚无中开始，这本身并没有错。虽然，阅读DELPHI的这些最本质的代码需要少量的汇编语言知识，但阅读这样的代码，可以让我们更深刻认识DELPHI世界的起源和发展的基本规律。即使看不太懂，能起码了解一些基本东西，对我们编写DELPHI程序也是大有帮助。

第二节 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数据的理解。

有了`类的类型，就可以将类作为变量来使用。可以将类的变量理解为一种特殊的对象，你可以象访问对象那样访问类变量的方法。例如：我们来看看下面的程序片段：

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++语言中，没有类的类型。全局对象的实例是在编译时就存在于全局数据空间中，函数的局部对象也是编译时就在堆栈空间中映射的实例，即使是动态创建的对象，也是用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。其实，进程最小的堆栈空间大小就是$5000，它是根据编译DELPHI程序时在ProjectOptions中Linker页中设置的Min stack size值，加上$1000而得到的。堆栈是由高端地址向底端增长的，当程序运行的堆栈不够时，系统将自动向地端地址方向增加堆栈空间的大小，这一过程将把更多的实际内存映射到进程空间。可在编译DELPHI程序时，通过设置ProjectOptions中Linker页中Max stack size的值，控制可增加的最大堆栈空间。特别是在含有深层次的子程序调用关系或运用递归算法的程序中，一定要合理地设置Max stack size的值。因为，调用子程序是需要耗用堆栈空间，而堆栈耗尽之后，系统就会抛出“Stack overflow”的错误。

似乎，从堆栈空间之后的进程空间就应该是自由的空间了吧。其实不然，WIN32的有关资料说，$80000000之后的2G空间是系统使用的空间。看来，进程能够真正拥有的只有2G空间。其实，进程能真正拥有的空间连2G都不够，因为从$00000000到$00400000的这4M空间也是禁区。

但不管怎样，我们的进程可以使用的地址还是非常广阔的。特别是堆栈空间之后到$80000000之间，是进程空间的主战场。进程从系统分配的内存空间将被映射到这块空间，进程加载的动态连接库将被映射到这块空间，新建线程的线程堆栈空间也将映射到这块空间，几乎所有涉及分配内存的操作都将映射到这块空间。请注意，这里所说的映射，意味着实际内存与这块虚拟空间的对应，没有映射为实际内存的进程空间是无法使用的，就象调试时CPU窗口指令框中的那一串串的“????”。