系统理解Win32API和MFC.docxVIP

系统理解Win32 API和MFC(上)作者:  HYPERLINK mailto:xinxiu123@ 温昱 作者主页:  HYPERLINK \t _blank  Win32 API是微软的操作系统Windows提供给开发人员的编程接口，它决定了我们开发的Windows应用程序的能力。MFC是微软为开发人员提供的类库，在某种意义上是对Win32 API的封装。本文试图从全局角度对Win32 API和MFC进行理解──给出二者的概念模型。本文使用UML描述概念模型。Win32 API本不是面向对象的，我用面向对象的观点去理解它，无非是想表达其全局。 本文参考了MSDN、相关书籍和网上的一些资料，在此一并感谢。一、Win32 API的概念模型Win32 API的object有3种：user obj，gdi obj，kernel obj。但是，如果一点不考虑OS本身的支持，就会在有些问题上疑惑，因此，我这里把“operation system负责将中断封装成message”加上。1、user obj、gdi obj、kernel obj、system 4者的关系 由于是kernel obj部分负责将另外3者联系起来，因此我们在下图中直接深入到kernel obj部分内部。从图中看到，在内存中运行的，除了“负责将中断封装成message”的system支持部分，还有另外3类object：kernel obj、user obj和gdi obj，每个obj都有一个句柄handle与之对应。其中，gdi obj建立了待开发的Windows 应用和外部输出设备的联系，kernel obj中的file建立了内存和永久存储设备的联系。具体说，内存中的file从可以从硬盘上来，如果这个file是可执行文件，它将生成module，module运行起来就是process，process可以包含多条thread，而thread的运行映象最终还是来自于file。thread是kernel obj中最重要的一个，因为消息队列就是thread拥有的，只有thread才能够接受message。对gdi obj、urser obj和file的操作，也是发生在thread中的。所以书都讲，process至少拥有一个thread。2、展开“system负责将中断封装成message”部分下面展开“system负责将中断封装成message”部分，尽早解除对“message到底是怎么形成的”的困惑。3、展开“gdi obj”部分 开发人员可以通过gdi obj将app的信息反馈给User。从图中看到，gdi obj有8种，其中7种为：bmp，brush，pen，region，font，palette，path。另一种比较特殊的是DC，它可以被理解为一种容器，程序员通过调用SelectPallette()将pallte放入容器，通过调用BeginPath()和EndPath()将path放入容器，其它5种gdi obj，是通过调用SelectObject()放入容器的。DC又具体分为4种，其中DisplayDC就是最常用的用来支持我们“画Window”的DC。 另外，如果觉得不好理解，请参考composite设计模式。4、展开user obj部分 4.1 第1次迭代 window在Windows应用开发中占有重要地位。从图中看到，window可分为3种：desktop，top-level window，child window。所有window被OS组织成tree，有专门的数据结构来管理。desktop就是树根，desktop的子节点是top-level window，top-level window的子节点是child window，child window仍然可以有子节点，同样归属于child window。tree数据结构中还记录了4种重要信息，是4种指针：parent指针、child指针、brother指针、owner指针。这样，从任何一个window就能很容易地找到其它window了。 好了，暂且得到 window = desktop + topLevel + child 的结论，看看全局先。毕竟，一步到位有时候并不好。从图中看到，window确实占有重要地位。从逻辑是讲，thread是window的拥有者；但是，所有window一起决定了屏幕看起来是上面样子，何况点击任何一个window都会使window得相互覆盖关系发生变化，对所用window进行统一管理是必须的，所以OS又不得不统一用window tree来管理window，反映复杂的window关系。每个window都必须有一