四、标准的事件驱动模型与牛鼻子
其实,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事件驱动模型