第五章 走得太远，别忘了回家的路(4) ——《箴言》第三章 Windows运行机理之读书笔记之一

四、标准的事件驱动模型与牛鼻子

其实，Windows GUI程序的所谓的标准（或基本）模型（以窗口过程为可重入单位的事件驱动模型），不过是MS给我们指引（或搭建）的一座晃荡不堪的人造浮桥而已，它并不是Windows GUI程序的真实模型。这个真实模型，其实Windows也已经说过了，只是没有把它的真正地位说明而已。Windows云[todo]，只有在用户程序（线程）调用GetMessage或PeekMessage这些执行message retrieval code期间Windows才接管控制权，进行内务处理，如处理其他线程的Incoming nonqueue messages，处理系统发送的消息，定时器消息等。这就是Windows GUI程序（线程）的真实的基本模型。如果不考虑与操作系统线程的关系、地位，那么这就是Windows GUI程序（线程）的真实的基本模型的几乎一切。这样看来，Windows 窗口过程的重入性倒退居及次、第二位了。GUI线程的控制权才是首要的，即事件驱动系统的控制权是在Windows GUI系统手中、还是在GUI线程手中才是首要的。如果事件驱动系统的控制权在GUI线程手中，那么在没有GUI线程的允许下GUI系统就不能随便横插一脚；如果事件驱动系统的控制权在GUI系统手中，那么一般情况下大抵还是有章可循，在其他情况下就不是GUI系统（目前的）所能控制的了，当然也不是GUI线程所能控制的。【暂不考虑SendMessage之拯救的因素】

在真实模型下，首先把握事件驱动系统的控制权问题，其次才是其他问题如窗口过程的重入性问题等等。【】

试举个例子【？MVC模型：界面面膜、黄油，面膜下面那些真实的东西、面包；Windows推荐的那种模型混淆了Model与VC的关系，MFC下的Document/View（/Frame）模型相比之下有所进步，但还是（简单？）直接将Document近似看作Model，其实Model的意义要丰富得多、深刻得多。相对性。外在性。接口。】：


如果考虑与操作系统线程的关系、地位，那么Windows GUI程序（线程）的真实模型还需进一步说明，在这一点上，就如其他non-GUI的Win32线程一样，它们都是在操作系统线程模型这个大舞台上活动的，GUI线程并没有参与到操作系统线程模型之中，更没有凌驾于其上的地位，它只不过是在其上建立的一种应用模型而已。所以就GUI线程的事件驱动模型在其中的地位、关系而言，他们之间是独立的、透明的。GUI线程中的事件驱动控制权的调度、移交，这些都不过是GUI线程之事件驱动系统自己的事情，对操作系统线程的管理者而言，这是GUI线程之事件驱动系统自己的家务事，反正CPU该分给你的都按规则（就算是）分给你了，至于你怎么进一步分配那是你的事情了，你们愿意提早让出CPU那也是你们的事。【用户APC的执行不会顾及事件驱动系统的情况，例子，证据】


Windows NT 4.0以后GUI系统虽然移居核心态，但终究是个天外来客，没有其真正的“核心态”地位，号称Windows的操作系统却没有Window（GUI）的真正当家的地位：Windows NT对象管理器没有Window的身影；因此安全机制也将Window摒弃于外【缺乏安全的GUI系统】；在线程模型中没有Window、GUI的控制逻辑的地位，只是其上的一种应用模型而已；还是《Inside Windows NT》（第二版）中说得对，仅仅由于性能原因而移入核心态，对其它（原来的）核心态部件影响极少。《大道至简》（第二版2007年）声称要通过“追溯Windows内核”去理解“事件驱动的本质”。而真正要理解事件驱动系统的本质，至少需要（不能不）去追寻没有Windows的“史前”时代！

总之，如果要进一步追究“Windows的消息内核原理”，从Windows事件/消息驱动系统本身来说，还需要对消息的类型、消息的来源、消息的收发、消息的存储、消息的优先级、消息的调度机制、窗口过程及其重入性、消息（提取）循环、消息本体、消息的关系模型、消息/处理过程的完整性及并发与同步、消息执行环境、消息执行模型等进一步追究。

五 当COM模型（COM/OLE/ActiveX[.NET?]）遇上Windows事件驱动模型