$GetMessage-PeekMessage-SendMessage内核解析核心要点.doc

最近忙公司的项目（或是毕设吧），发现很长时间没有总结了。是该换换脑子了。 “为什么没有SendThreadMessage呢？”这个问题，就来自自己平时实现的一些程序逻辑中。在一些具体的场景中，对像我这样的初学者来说，往往喜欢通过windwos的消息机制来完成UI线程和worker线程之间的同步，而不是去通过信号量或其他的去做。所以，这个问题一直困惑了自己很久。而现在，就来搞明白这个、 google一下，这个问题，在一个大牛（Raymond Chen） /b/oldnewthing/archive/2008/12/23/9248851.aspx）的博客中提到了，而且也引发了很多讨论。我这里简单的”翻译”一下Raymond Chen自己的看法。 ”想象中的SendThreadMessage是如何工作的呢？调用SendMessage 把消息直接分发给窗口过程？但是我们没有看到消息泵，想象中的SendThreadMessage将会把消息分发给谁呢？因为我们没有‘thread window procedure’这样的东东去处理我们的消息。 是的，我们可以自己在我们的线程中做一个消息泵，但是，想象中的SendThreadMessage，需要等待这个消息处理完毕。但是，我们怎么能够知道这个消息处理完毕了？因为我们不可能等待DispatchMessage返回，而DispatchMessage失败则是因为我们并不知道应该往哪一个窗口分发消息。window manager给线程发送一个消息，仅此而已。 你可能会认为，我们可以等待知道下一个GetMessage or PeekMessage，这样我们可以确定这个消息解决了。但是，我们却不能保证下一个消息检索函数(GetMessage PeekMessage)，是来自我们之前的消息泵。比如，我们这个线程消息，启动了一个模态窗口，是的。当我们的消息检索函数告诉我们这个消息已经处理完毕了。但是，事实上那个模态窗口还在，因为他自己又创建了一个消息泵。“ 这段虽然不长，但是却另我头大无比。GetMessage ，? DispatchMessage。这2个基本的函数，天天用，但是却对他们的行为知之甚少，算上第一次写HelloWorld 到现在，至少也有1年了，依然朦胧，感到十分惭愧。而这也就是这篇总结要做的。而这的确是一个庞大的工程，因为要了解这2个函数，需要把握windows的消息机制。而windwos 并没有给我们源代码参考，这里参考ReactOS的实现，虽然不是windows正统，但是，应该差不远，至少是和win2003的相似。开始步入正题。 我们首先需要了解的是，UI线程 和我们的普通的Worker线程之间的区别是什么。 msdn? /en-us/library/ms644927提到： ”To avoid the overhead of creating a message queue for non–GUI threads, all threads are created initially without a message queue. The system creates a thread-specific message queue only when the thread makes its first call to one of the specific user functions; no GUI function calls result in the creation of a message queue.“ 既然，系统创建每一个线程时都是普通的non–GUI thread，直到GDI， User函数调用，才为线程创建消息队列，那么我们就从这些函数调用开始。 windwos在开始时，和linux一样 图形这部分是在用户空间中的进程负责，后面为了减少进程之间的环境切换，而放入了内核中。那么在系统调用这层，我们就看到了有2种情况。一种调用是原来的”内核”的调用，而另一种是新加进来的原来在用户空间的调用，这部分被称为扩充系统调用，这部分代码被放在了可以动态安装的模块win32k.sys。与之对应，系统的调用表就有了2个，一个是只包括之前的”来自内核的系统调用“，另一个则在之前的基础上，增加了图形图像的系统调用。当我们的系统调用被发现是扩充系统调用时，也就是，原来的的表不能满足我们的要求。windwos会将会扩充系统调用表。并装载win32k.sys模块。那么，我们的普普通通的线程就开始变为GUI线程了。 激动人心的旅程就从这里开始了。 开源代码就是好，随意都能够贴出来。 NTSTATUS NTAPI PsConvertToGuiThread(VOID) { ULONG_PTR