win32程序概况

学习MFC之前朋友建议我先学Windows编程，的确还是有道理的，毕竟MFC把自己“裹得太严实”，如果有win32的编程经验势必可以更好地掌握MFC。所以喽，文中和大家一起分享我学习win32部分后的总结。

Windows程序和操作系统之间的爱恨纠葛请看下图：

1中表示的是系统消息队列。当操作系统启动并初始化时，线程Raw Input Thread(RIT)就会启动，并创系统硬件输入队列(SystemHardware Input Queue)(SHIQ). 对于外部的硬件事件（鼠标或者键盘），硬件驱动会将事件转换成消息，并存放到SHIQ中，而RIT线程就专门负责处理SHIQ中的消息，把消息分发到对应线程的消息队列里面。你可能会问，系统消息队列怎么知道这个消息是属于哪个窗口对应的线程呢？这是因为消息产生的时候，消息结构体中保存了它所属的窗口句柄，根据窗口句柄的指示，在USER模块的协助下，当然就能找到该消息所属的线程了。

2中表示的是线程消息队列。线程的消息队列主要由三种，发送消息队列，投递消息队列和输入消息队列（关于这三种队列已经在Windows消息相关的文章介绍过了，就不再重复了）。

3中表示USER模块。USER模块是Windows用户界面相关应用程序接口，用于包括Windows处理，基本用户界面等特性，如创建窗口和发送消息。

4中列出了一个win32程序的大致轮廓，其中，DispatchMessage函数将相应的消息发送到消息处理函数。那么问题又来了，DispatchMessage函数中并没有指明发送到哪个处理函数，它是哪来的自信？还是老规矩，消息生成时，操作系统已根据当时状态，为它标明了所属的窗口，而窗口所属的窗口类又已经标明了相应的窗口函数，所以DispatchMessage最后在USER模块的帮助下把消息正确地交到了窗口函数手中。

5中是窗口函数的大致轮廓。窗口函数的体积如何，主要看该函数关心的消息有多少。但是，不论什么消息都是需要被处理的，如果我们没有在自己的窗口函数中处理，那么就在default处调用DefWindowProc，这是Windows内部默认的消息处理函数。

还有一个问题是：窗口函数为什么需要是一个callback函数？因为除了我们需要调用窗口函数以外，很多时候操作系统也需要调用窗口函数（例如当某个消息产生或某个事件发生）。窗口函数设计为callback形式，才能开放出一个接口给操作系统使用。

藕断丝连的RegisterClass和CreateWindows如下图：

由上可以看到，在产生窗口之前我们需要注册一个窗口类。窗口结构中将指定相关联的某些资源、窗口类的窗口函数和窗口类的名称等相关参数。后面的窗口创建函数中将会用到要创建窗口实例的窗口类的名称，还会指定窗口的具体样式等参数。不过CreateWindow只产生窗口，并不显示窗口，所以后面还需要调用ShowWindow将它显示在屏幕上。最后，我们希望先传递一个WM_PAINT消息给窗口，以驱动窗口的绘图操作，所以还调用了UpdateWindow。

Windows程序的生命周期：

 0.Windows shell检测到有一个Windows程序将被执行，于是调用加载器把该程序加载，然后调用C startup code，后者再调用WinMain，开始执行程序。WinMain的四个参数由操作系统传递进来。

1.程序初始化过程中调用CreateWindow，为程序建立一个对应的窗口，作为程序展示的舞台。CreateWindow产生窗口之后会送出WM_CREATE给窗口函数，在消息处理函数中就可以做一些必要的初始化操作（例如配置内存、打开文件、读入初始数据……）。

2.在程序运行过程中，不断以GetMessage（或PeekMessage）从消息队列中抓取消息。如果消息是WM_QUIT，GetMessage会传回0而结束while循环，进而结束整个程序。

3.DispatchMessage通过Windows USER模块的协助与监督，把消息分派至窗口函数。消息将在窗口函数中被辨别和处理。

4.程序不断进行第2和第3步的操作。

5.当使用者按下系统菜单中的“Close”命令时，系统送出WM_CLOSE消息。通常程序的窗口函数不拦截此消息，于是DefWindowProc将会处理它。

6.DefWindowProc收到WM_CLOSE之后，会调用DestroyWindow把窗口清除。DestroyWindow本身又会送出WM_DESTROY消息。

7.程序对WM_DESTROY消息的标准反应是调用PostQuitMessage。

8.PostQuitMessage就只是送出WM_QUIT消息，准备让消息循环中的GetMessage获得，最后入步骤2，结束消息循环。