windows和x系统是相似的，然而它既不以进程为根本，又不以线程为根本，而是以窗口为根本的，由于它的过程的每一个环节都是在本机进行的，所以它必然需要在进程，线程以及窗口之间进行更进一步的细分，毕竟在没有虚拟机硬件的支持下，一台机器的最小元素就是线程(在多处理情况下)。具体过程是，当有鼠标键盘或者触摸屏之类的东西有输入事件时，windows系统会将这个事件排入到当前进程的当前线程的消息队列中，注意是基于线程的，然后由当前进程应用程序通过GetMessge这个API依次取出一个消息，然后再次压入windows系统，而后windows系统将这个消息分发到当前的窗口，注意这个过程中，将消息分派到当前窗口是通过线程来进行的，第一个过程是系统将事件排入当前线程，第二个过程是系统将一个消息排入当前线程的窗口，因为一个线程可能不仅仅包括一个窗口，windows系统的一切可操作元素都是通过窗口来组织的(witget)，就连标题栏也是一个窗口。
这就可以看出，windows的GUI和x系统的GUI的不同之处，由于x系统中，是通过socket这种进程间通信的方式来进行通信的，所以输入设备和显示这种事天生就是接触耦合的，况且，显示图形的机制是用户空间完成，输入设备通过设备文件(/dev/input/mice...)被读到用户空间，然后x server进程通过x网络协议分发这些事件到各个x client。x系统的进程间通信天生就不假设是同一台机器的，因此就不能用线程这种轻量级的机制来进一步裁剪机制--毕竟线程不能在不同机器间被认同--它们不能共享进程地址空间，所以x系统的最小单元就是进程。在windows系统中，由于事件和显示都是同一台机器完成的，所以尽可以充分使用操作系统内部的机制，譬如线程来更加高效的完成，因此windows操作系统中就充分使用了线程消息队列，然后在线程环境中将各个消息分派到当前窗口，这是因为这一点，GetMessage之后不能手工调用窗口过程函数，而要通过DispatchMessage函数来分发同一线程的消息到可能有多个的同一线程的不同窗口的之一。
明白了windows的消息处理原理，很容易写出一个windows版本的xeyes程序，然而在看既有的wineyes程序源代码的时候，发现它也是通过timer实现的，这个令人很不爽，正如在linux中遇到的那样！因此有必要改造之，既然我们的linux改造版的xeyes使用了和windows类似的事件循环机制，那么我们的windows也可以和linux更加靠拢，那就是不调用DispatchMessage函数，而直接调用窗口处理函数，前提是消息确实是发送给我们这个窗口的--毕竟消息是从线程的消息队列中取出的而消息的目的地却是基于窗口的--一个线程不止一个窗口！整个思路是这样的，我们一直都以为windows的处理机制和x window有着类似之处，只不过windows由于x server和x client处于一个操作系统空间，因此它们可以充分使用操作系统的特性，比如线程，比如无消息时调度等特性。既然它们的本质是一样的，那么它们的实现也可以相通，既然x系统可以使用xlib来实现一个消息循环，那么windows也是可以的，只要我们排除掉它使用的操作系统特性即可，因此，我们加一个限制条件：
while(GetMessage(...)) {
TranslateMessage(...);
if (msg.hwnd == hWnd) {
直接调用窗口函数
} else {
DispatchMessage(...);
}
}
可见，只要直接调用窗口函数就可以了，而没有必要让操作系统dispatch消息了。然而除了因为一个线程可能对应多个窗口导致的消息不一定是给我们的这个原因外，还有什么原因导致必须调用dispatch呢？这和windows基于线程调度是有一定关系的，这与其说是一种完美的设计不如说是一种败笔，之所以这么设计为的就是操作系统更好的监控窗口函数的处理情况，如果直接调用窗口而不是调用dispatch，那么操作系统完全不知道你的窗口函数什么时候返回的，如果你的窗口函数正在绘图，此时将该线程调度出去是不合适的，除非它占用了太久的cpu或者有更要紧的事要做，因此windows操作系统最好能设法监控到窗口函数什么时候返回，以决定调度时机。这个机制无论如何都太复杂了，因此就简单性原则来说就是败笔，x系统就不需要这么做，因为它基于task_struct调度，简单，高效，不管task_struct到底是什么，因此linux也根本不觉得将正在绘图的task_struct调度出去有什么不合适的，在windows中，GUI有特权，在linux中GUI只是一个X进程，它没有特权，一般般！
下面就是wineyes的无timer版本，也不知道为什么，XXeyes怎么都使用timer来做，搞不懂：
...
#pragma comment(linker, "/subsystem:/"console/" /entry:/"WinMainCRTStartup/"") //便于调试，因为有console窗口
...
void setClippingRegion(HWND hWnd)
{
...//完全是wineyes的
}
void WinEyesUpdate(HWND hWnd, int ForceRedrawEyes)
{
...//完全是wineyes的
}
void WinEyesPaint(HWND hWnd)
{
...//完全是wineyes的
}
...
LRESULT CALLBACK PASCAL WinEyesWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
...//完全是wineyes的，但是去掉了WM_TIMER，因为这是无timer版的
}
BOOL WinEyesInit(HINSTANCE hInstance)
{
...//完全是wineyes的
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
while( GetMessage( &msg, NULL, (int)NULL, (int)NULL) ) { //和xlib类似的消息(事件)循环
TranslateMessage(&msg);
if (hWnd == msg.hwnd) { //如果消息是发给本窗口的，直接调用
WinEyesWndProc(msg.hwnd, msg.message, msg.wParam, msg.lParam);
}
else //注意，这是在从线程消息队列取消息，它可能不属于我们这个窗口，如果这样就调用dispatch，将之交由操作系统来处理，其实是操作系统负责将之路由到msg.hwnd
DispatchMessage(&msg);
}
...
这就可以看出，windows的GUI和x系统的GUI的不同之处，由于x系统中，是通过socket这种进程间通信的方式来进行通信的，所以输入设备和显示这种事天生就是接触耦合的，况且，显示图形的机制是用户空间完成，输入设备通过设备文件(/dev/input/mice...)被读到用户空间，然后x server进程通过x网络协议分发这些事件到各个x client。x系统的进程间通信天生就不假设是同一台机器的，因此就不能用线程这种轻量级的机制来进一步裁剪机制--毕竟线程不能在不同机器间被认同--它们不能共享进程地址空间，所以x系统的最小单元就是进程。在windows系统中，由于事件和显示都是同一台机器完成的，所以尽可以充分使用操作系统内部的机制，譬如线程来更加高效的完成，因此windows操作系统中就充分使用了线程消息队列，然后在线程环境中将各个消息分派到当前窗口，这是因为这一点，GetMessage之后不能手工调用窗口过程函数，而要通过DispatchMessage函数来分发同一线程的消息到可能有多个的同一线程的不同窗口的之一。
明白了windows的消息处理原理，很容易写出一个windows版本的xeyes程序，然而在看既有的wineyes程序源代码的时候，发现它也是通过timer实现的，这个令人很不爽，正如在linux中遇到的那样！因此有必要改造之，既然我们的linux改造版的xeyes使用了和windows类似的事件循环机制，那么我们的windows也可以和linux更加靠拢，那就是不调用DispatchMessage函数，而直接调用窗口处理函数，前提是消息确实是发送给我们这个窗口的--毕竟消息是从线程的消息队列中取出的而消息的目的地却是基于窗口的--一个线程不止一个窗口！整个思路是这样的，我们一直都以为windows的处理机制和x window有着类似之处，只不过windows由于x server和x client处于一个操作系统空间，因此它们可以充分使用操作系统的特性，比如线程，比如无消息时调度等特性。既然它们的本质是一样的，那么它们的实现也可以相通，既然x系统可以使用xlib来实现一个消息循环，那么windows也是可以的，只要我们排除掉它使用的操作系统特性即可，因此，我们加一个限制条件：
while(GetMessage(...)) {
TranslateMessage(...);
if (msg.hwnd == hWnd) {
直接调用窗口函数
} else {
DispatchMessage(...);
}
}
可见，只要直接调用窗口函数就可以了，而没有必要让操作系统dispatch消息了。然而除了因为一个线程可能对应多个窗口导致的消息不一定是给我们的这个原因外，还有什么原因导致必须调用dispatch呢？这和windows基于线程调度是有一定关系的，这与其说是一种完美的设计不如说是一种败笔，之所以这么设计为的就是操作系统更好的监控窗口函数的处理情况，如果直接调用窗口而不是调用dispatch，那么操作系统完全不知道你的窗口函数什么时候返回的，如果你的窗口函数正在绘图，此时将该线程调度出去是不合适的，除非它占用了太久的cpu或者有更要紧的事要做，因此windows操作系统最好能设法监控到窗口函数什么时候返回，以决定调度时机。这个机制无论如何都太复杂了，因此就简单性原则来说就是败笔，x系统就不需要这么做，因为它基于task_struct调度，简单，高效，不管task_struct到底是什么，因此linux也根本不觉得将正在绘图的task_struct调度出去有什么不合适的，在windows中，GUI有特权，在linux中GUI只是一个X进程，它没有特权，一般般！
下面就是wineyes的无timer版本，也不知道为什么，XXeyes怎么都使用timer来做，搞不懂：
...
#pragma comment(linker, "/subsystem:/"console/" /entry:/"WinMainCRTStartup/"") //便于调试，因为有console窗口
...
void setClippingRegion(HWND hWnd)
{
...//完全是wineyes的
}
void WinEyesUpdate(HWND hWnd, int ForceRedrawEyes)
{
...//完全是wineyes的
}
void WinEyesPaint(HWND hWnd)
{
...//完全是wineyes的
}
...
LRESULT CALLBACK PASCAL WinEyesWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
...//完全是wineyes的，但是去掉了WM_TIMER，因为这是无timer版的
}
BOOL WinEyesInit(HINSTANCE hInstance)
{
...//完全是wineyes的
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
while( GetMessage( &msg, NULL, (int)NULL, (int)NULL) ) { //和xlib类似的消息(事件)循环
TranslateMessage(&msg);
if (hWnd == msg.hwnd) { //如果消息是发给本窗口的，直接调用
WinEyesWndProc(msg.hwnd, msg.message, msg.wParam, msg.lParam);
}
else //注意，这是在从线程消息队列取消息，它可能不属于我们这个窗口，如果这样就调用dispatch，将之交由操作系统来处理，其实是操作系统负责将之路由到msg.hwnd
DispatchMessage(&msg);
}
...
}
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1271164
