消息机制与事件处理
1. 前言
1.1 什么是消息？
要更好地使用C++进行Windows编程，就需要进一步了解其消息机制。在Windows应用程序中，事件驱动是围绕着消息的产生和处理展开的，消息是对发生的事件的描述信息。消息通知程序有关事件的发生。一条消息包含有消息的名字、标识、消息发生时的一些参数，以及处理这条消息的函数入口指针。每当用户进行某种操作，比如鼠标单击或键盘按键，就会触发相应的事件。而事件是以消息的方式通知Windows应用程序的。一旦应用程序获得某条消息，就根据消息映射表查找相应消息的响应函数的入口地址，调用该函数处理消息，完成用户预期的功能。
1.2 在哪里产生消息？在哪里对消息进行响应？
在Windows操作系统中，应用程序主要以窗口的形式存在。窗口是一个可视的人机交互界面，用来接收各种事件，如用户键盘/鼠标事件、外设的请求事件、定时器的请求事件、信号量的请求事件等。因此，它也就成为应用程序控制消息的发送端和接收端。即Windows应用程序是围绕窗口进行的，窗口不仅提供了可视化的应用程序的界面，也是Windows消息的产生和响应的地方。
1.3 Windows系统如何实现消息机制？
消息的产生是由于相应的事件被触发；消息的发送以队列形式进行；消息响应遵循一定的顺序。MFC类库为这种消息响应机制提供了完整的处理功能。MFC类库中的很多类都具有处理相应消息的功能。在面向过程的程序设计方式中，对外设，比如鼠标、键盘等的控制是通过轮询方式进行，即分别定时查询这些设备的输入请求来完成的。而在Windows环境中，这些控制是通过消息机制完成的。因此，Windows也被称为“基于事件驱动的、消息机制的”操作系统。消息机制是Windows能进行多任务并发处理的基础，它保证了Windows下同时运行的程序能够协同作业。
在Windows中，应用程序都包含一个消息循环。该消息循环持续反复检测消息队列，查看是否有用户事件消息，这些用户事件消息包括鼠标移动、单击、双击、键盘操作和计时器到达等。事实上，这些事件首先被Windows系统接收到。当Windows接收到这些事件后，会产生一些相应的描述事件的消息，并且将这些消息分发到相应的应用程序。应用程序接到这些消息后，根据不同的消息查询消息映射，调用其相应的消息响应函数，完成一定的功能与过程。这一系列动作称之为消息响应。
2. Calling机制
调用(calling)机制从汇编时代起已经大量使用：准备一段现成的代码，调用者可以随时跳转至此段代码的起始地址，执行完后再返回跳转时的后续地址。CPU为此准备了现成的调用指令，调用时可以压栈保护现场，调用结束后从堆栈中弹出现场地址，以便自动返回。借堆栈保护现场真是一项绝妙的发明，它使调用者和被调者可以互不相识，于是才有了后来的函数和组件，使吾辈编程者如此轻松愉快。
3. Callback机制
调用机制并非完美。回调函数就是一例。函数之类本是为调用者准备的美餐，其烹制者应对食客了如指掌，但实情并非如此。例如，写一个快速排序函数供他人调用，其中必包含比较大小。麻烦来了：此时并不知要比较的是何类数据--整数、浮点数、字符串？于是只好为每类数据制作一个不同的排序函数。 更通行的办法是在函数参数中列一个回调函数地址，并通知调用者：君需自己准备一个比较函数，其中包含两个指针类参数，函数要比较此二指针所指数据之大小，并由函数返回值说明比较结果。排序函数借此调用者提供的函数来比较大小，借指针传递参数，可以全然不管所比较的数据类型。被调用者回头调用调用者的函数（够咬嘴的），故称其为回调（callback）。
回调函数使程序结构乱了许多。Windows API函数集中有不少回调函数，尽管有详尽说明，仍使初学者一头雾水。恐怕这也是无奈之举。无论何种事物，能以树形结构单向描述毕竟让人舒服些。如果某家族中孙辈又是某祖辈的祖辈，恐怕无人能理清其中的头绪。但数据处理之复杂往往需要构成网状结构，非简单的客户/服务器关系能穷尽。
4. 操作系统与应用程序的关系——广义回调/消息机制
Windows系统还包含着另一种更为广泛的回调机制，即消息机制。消息本是Windows的基本控制手段，乍看与函数调用无关，其实是一种变相的函数调用。发送消息的目的是通知收方运行一段预先准备好的代码，相当于调用一个函数。消息所附带的WParam和LParam相当于函数的参数，只不过比普通参数更通用一些。应用程序可以主动发送消息，更多情况下是坐等Windows发送消息。一旦消息进入所属消息队列，便检感兴趣的那些，跳转去执行相应的消息处理代码。操作系统本是为应用程序服务，由应用程序来调用。而应用程序一旦启动，却要反过来等待操作系统的调用。这分明也是一种回调，或者说是一种广义回调。
其实，应用程序之间也可以形成这种回调。假如进程B收到进程A发来的消息，启动了一段代码，其中又向进程A发送消息，这就形成了回调。 这种回调比较隐蔽，弄不好会搞成递归调用，若缺少终止条件，将会循环不已，直至把程序搞垮。若是故意编写成此递归调用，并设好终止条件，倒是很有意思。但这种程序结构太隐蔽，除非十分必要，还是不用为好。
5. 同步调用与异步调用
利用消息也可以构成狭义回调。上面所举排序函数一例，可以把回调函数地址换成窗口handle。如此，当需要比较数据大小时，不是去调用回调函数，而是借API函数SendMessage向指定窗口发送消息。收到消息方负责比较数据大小，把比较结果通过消息本身的返回值传给消息发送方。所实现的功能与回调函数并无不同。当然，此例中改为消息纯属画蛇添脚，反倒把程序搞得很慢。但其他情况下并非总是如此，特别是需要异步调用时，发送消息是一种不错的选择。假如回调函数中包含文件处理之类的低速处理，调用方等不得，需要把同步调用改为异步调用，去启动一个单独的线程，然后马上执行后续代码，其余的事让线程慢慢去做。一个替代办法是借API函数PostMessage发送一个异步消息，然后立即执行后续代码。这要比自己搞个线程省事许多，而且更安全。
6. 事件与对象
如今我们是活在一个object时代。只要与编程有关，无论何事都离不开object。但object并未消除回调，反而把它发扬光大，弄得到处都是，只不过大都以事件（event）的身份出现，镶嵌在某个结构之中，显得更正统，更容易被人接受。应用程序要使用某个构件，总要先弄清构件的属性、方法和事件，然后给构件属性赋值，在适当的时候调用适当的构件方法，还要给事件编写*处理例程，以备构件代码来调用。何谓事件？它不过是一个指向事件例程的地址，与回调函数地址没什么区别。
不过，此种回调方式比传统回调函数要高明许多。首先，它把让人不太舒服的回调函数变成一种自然而然的处理例程，使编程者顿觉气顺。再者，地址是一个危险的东西，用好了可使程序加速，用不好处处是陷阱，程序随时都会崩溃。现代编程方式总是想法把地址隐藏起来（隐藏比较彻底的如 VB 和 Java），其代价是降低了程序效率。事件例程使编程者无需直接操作地址，但并不会使程序减速。更妙的是，此一改变，本是有损程序结构之奇技怪巧变成一种崭新设计理念，不仅免去被人抨击，而且逼得吾等凡人净手更衣，细细研读，仰慕至今。
7. 消息与事件的区别
- 事件是一个动作——用户触发的动作。
- 消息是一个信息——传递给系统的信息。
事件与消息的概念在计算机中较易混淆，但本质不同：
事件由用户触发且只能由用户触发，操作系统能够感觉到由用户触发的事件，并将此事件转换为一个特定的消息发送到程序的消息队列中。
这里强调的是
- 可以说“用户触发了一个事件”，而不能说“用户触发了一个消息”。
- 用户只能触发事件，而事件只能由用户触发。
一个事件产生后，将被操作系统转换为一个消息，所以一个消息可能是由一个事件转换而来或者由操作系统产生。
总结事件和消息的来源
事件：只能由用户通过外设的输入产生。
消息：产生消息的来源有三个
(1) 由操作系统产生。
(2) 由用户触发的事件转换而来。
(3) 由另一个消息产生。
注： 上述描述似乎不太严谨，如定时器事件应该算是内部事件，并非用户产生。
个人总结
程序是数据的流动。所有的编程技术(tricks)都在往两个方面去努力：
- 减少时间消耗——时间调度算法（操作系统、进程、线程）
- 减少内存(空间)消耗——内存管理
- 时间与空间互换与平衡
- 在开发效率和执行效率之间寻求平衡(trade-off)
2.再说什么是事件驱动的程序。一个典型的事件驱动的程序，就是一个死循环，并以一个线程的形式存在，这个死循环包括两个部分，第一个部分是按照一定的条件接收并选择一个要处理的事件，第二个部分就是事件的处理过程。程序的执行过程就是选择事件和处理事件，而当没有任何事件触发时，程序会因查询事件队列失败而进入睡眠状态，从而释放cpu。
3.事件驱动的程序，必定会直接或者间接拥有一个事件队列，用于存储未能及时处理的事件。
4.事件驱动的程序的行为，完全受外部输入的事件控制，所以，事件驱动的系统中，存在大量这种程序，并以事件作为主要的通信方式。
5.事件驱动的程序，还有一个最大的好处，就是可以按照一定的顺序处理队列中的事件，而这个顺序则是由事件的触发顺序决定的，这一特性往往被用于保证某些过程的原子化。
6.目前windows,linux,nucleus,vxworks都是事件驱动的，只有一些单片机可能是非事件驱动的。
简单记录自己对于 消息驱动 和 事件驱动的理解。
关于这二者的具体区别，于实现上来说，二者都是 注册绑定，然后交付执行。
消息驱动模型在注册的时候仅仅注册一个回调函数作为处理函数。
而事件驱动模型则需要注册多个函数作为处理函数。
消息驱动模型由于处理函数只有一个的缘故，
故需要在回调函数中使用switch等手段，
对消息进行派发并具体处理。
而事件驱动模型则需要在各个回调函数中处理各自的事物。
所以从设计角度说，
消息驱动模型的复用性高于事件驱动模型，
或者说事件驱动模型一般用于处理某个特定的问题。
而造成这种情形的原因是，
消息驱动模型不需要知道具体的消息含义，
而事件驱动模型则需要知道具体的事件含义，否则无法通过回调函数处理。
