关于消息机制这个话题是很有意思的，希望继续探讨。

vcbear:
我大力支持你!!!

支持！！！
是的，我在使用SendMessage和PostMessage时也发现了之间的区别，SendMessage是要等待返回的，而PostMessage只是将消息投递到消息队列中，所以SendMessage可能会引起消息阻塞的情况，而且可能会将消息的顺序搞错。在使用时我们发现，用PostMessage可以完成的工作，SendMessage却不能，我用SPY++仔细查看了具体消息时发现，如果在SendMessage时将其余的消息都发了就能完成与PostMessage一样的工作。

SendMessage会挂起，一直等到处理结果返回，如果接受消息的进程也挂起了，那两个进程就死
翘翘了。

我的问题：1 是否每个窗口都会有自己的 Message Queue
2 GetMessage是从哪个Message Queue中取消息？

对于ray_czh的第一个问题应该是这样的：
每个窗口都有自己的一个线程，每个线程都有自己的消息队列。
见我发的问题里描述的THREADINFO和消息队列。
至于GetMessage,是获取消息的堵塞方式（peekmessage是异步方式），
见MSDN:
Unlike the GetMessage function, the PeekMessage function does not wait for a message to be placed in the queue before returning.
但这两条函数都会先检查队列标志（见GetQueueStatus和MsgWaitForMultipleObjects）
然后从队列里取到消息。
》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》
再重申一次，bear的意见都是个人理解，有不当之处，随时接受当头棒喝。力求不误导
祖国的花朵儿。

to vcbear :
我非常欢迎专题讨论，我大力支持，不够分可以向我这个菜鸟要！！！！

我觉得在核心级有一个系统消息分发机制，而对于每一个进程和线程来说应该有一个消息队列，
这样似乎是很合理，而在windows 中，线程分为有消息线程和没消息线程（步知我说的对不对）。

建议看看WTL的原码，这个框架，对消息机制的处理相当明了，一看就明白

按一下键盘，是否WM_KEYDOWN的消息发给了所有的线程？

来csdn第一帖：望各位多加帮助。
to ray_czh:
   WM_KEYDOWN只发入系统当前线程输入对列。
to vcbear:
    关于消息机制，我以下只针对windows 2000 server说说自己的一点拙见。如果有什么问题希望能共同控讨。
    在WIndows 2000中PTHREADINFO结构我觉得应该存放在ETHREAD(具体见WIndows 2000 DDK或我的主页http://webcrazy.yeah.net/。)的一个Win32Thread的结构中。这个结构不仅有Thread的一些hwnd信息。(见我的个人网站)。还有当前线程的消息输入对列。至于你提及的问题在Jeffery Richter的书上有较详细的说明。另外好像还有一本<<Windows Internal>>讲得较详细。

SendMessage函数是同步的，需要等待返回值；而PostMessage是异步的，不等待返回值。所以如果在一个线程往另一个线程用SendMessage发消息，那么接收消息的线程的消息循环必须在运行，而不能被block。

其实这个是常用的一种编程技巧，因为伟大的M$的创造了MFC，使得这一机制得以广为使用，这个技术是相当巧妙的（具体的好处看Design Pattern）。但这个机制不是万用可爽的。在因为消息机制把太多的事务都抛到消息链，所以在一些实时的处理中，就不能把任务处理机制嵌到Window消息机制里.一来实时性不能满足，二来程序结构也不好维护。其实OO过后，就要过渡到Design Pattern ，否则 OO完全是空谈而流于形式。

参考一下Unix的进程通信方法也许会更好地理解消息驱动，我曾经在Unix下做过消息驱动的多进程程序，觉得Unix下消息驱动编程思路清晰，性能稳定，比Windows下好多了。

to artgolf
能简单介绍一下吗?或者贴点什么文献。

听你言必称Jeffrey Richter，好像你读过他的大作，但谈论内容上又不像精读过。
如果你真的想了解这方面的指示，应该好好通读一下“Advanced Windows”.
关于PostMessage/SendMessage是不应该用于跨进程的消息发送上的，取而代之的是PostThreadMessage/SendMessageTimeout等。另：不要迷信和沉沦于所谓未公开的技术内幕，很多微软以外的软件商都制作出了伟大的产品，他们并不知道什么内幕。另2：vcbear的回答大错特错。应该是：每个进程可有一个或多个线程；每个线程只有一个消息队列（!）；一个线程可以有多个窗口，这多个窗口共享同一个消息队列！

vcbear:
我支持你!!!!

完全同意newx的看法。
Jeffrey Richter的书中文的有两本，一本是只讲NT的，一本是讲95/NT的。
后一本是前一本的扩充。不过出版的比较早。很值得读一读。
另外对这个题目的讨论可以去看一看DDK的文档，有帮助的。

感谢newx.
我也是初学vc，只有在windows下打滚的本领，所以UNIX什么的，在时间和精力上暂时不能
考虑。我知道UNIX/LINUX确实体现了很多优良的编程思想，但是在目前来说，我还是想
把windows的机制弄清楚。不管怎么说，windows也算是一种成熟的产品。
Jeffrey Richter的书我确实看的不是很深入，否则可能我都不用发这个帖子了。本意就是
想让大家都来给点提示（回报的只是分了，呵呵）。现在刚好有了时间，我会好好看看书的。进程间确实不应该用SendMessage,但是PostMessage在一般应用上是值得使用的。从
更高的要求上说，用SendMessageTimeOut,SendMessageCallBack在进程间都不应该
使用，除非你想在消息中使用指针数据。至于一个线程是否能有多个窗口，我表示怀疑。至少在一般编程上，每个窗口都应该有自己
的WindowProc.当线程获得消息，如果是隶属于自己窗口的，就会把HWND信息取掉并放入
消息队列。如果有多个窗口...那就不能把hWnd取掉，在我看的书上没有提到，也许是我看的
是一些无聊的“内幕”书的原因。我近来看的是清华的《windows高级编程指南》。感谢myb123，Com235和hhb等同志的支持。虽然现在我们现在还不懂，但是我们够执着。
学习的同时，我不会忘记给这个帖子加分的。

各位，我不知道为什么非要说Windows有很多的消息队列呢？
我不知道Jeffrey Richter是谁（可能是我孤陋寡闻吧），也没有看过Jeffrey Richter的书！
但我一直认为Windows每个线程应该只有一个消息队列，至少我在DOS下模拟Windows的消息机制是是这样作的，至于SendMessage()和PostMessage()应该很简单，使用PostMessage()函数是将消息插入到消息队列的首位置，而SendMessage()函数则是将消息插入到消息队列的尾位置（最基本的数据结构，我在DOS下模拟消息机制是就是这样实现的，效果还不错），这样既方便程序的维护，实现也很方便吗，何乐而不为呢？
本人转到Windows平台编程时间还不是很长，理解也不是很深，所以也不知道我的理解是否正确！
另外我也认为newx说的很对！
的确：每个进程可有一个或多个线程；每个线程只有一个消息队列（!）；一个线程可以有多个窗口，这多个窗口共享同一个消息队列！

我记得在某处看到过，光是处理键盘输入就不简单，牵扯好几个队列，建议知道的人说详细些。Jeffrey Richter的书我也看过，很好，难得的中文资料！遗憾我只看了映像文件和DLL的部分。

在windows中可以同时存在任意数目的窗口,但基本的消息队列只有两种.系统队列(System Queue)和线程消息队列(thread-specific message queue)
系统队列被整个系统共享的,系统队列在一个Windows系统中有且仅有一个.而在每一个GUI线程都拥有一个线程消息队列.windows系统中为了避免系统过载,所以并不为非GUI线程创建消息队列.系统仅当线程第一次调用Win32 User或者GDI函数是创建一个线程消息队列.
键盘事件和鼠标事件被系统捕获后被翻译成相应的消息放入系统消息队列,在由系统判断消息应该属于那个窗口,并将这条消息发至相应的线程.当线程的消息对列收到这条消息后用DispatchMessage函数将消息传递到相应窗口的WindowProc.
关于SendMessage和PostMessage的区别,PostMessage只是将消息放入消息队列,所以不必等待返回,而SendMessage则是直接调用窗口的WindowProc,所以必须等待返回.
本来想多写一点,可敲字太累了,下次再说.

Jeffrey Richter就是厉害。佩服！！
我正在看核心编程。光下Plateform SDK就让我找了老半天，才能编译例子。
看来64位Windows不远了。我们的软件也要注意平台可移植，国际化的问题。

dengfz: Platform SDK哪里找到的?给提供点线索,MS网站上下载的装不上.

感谢多位朋友对我的支持，yujing的论述尤其让我印象深刻。当然，大家都在学习，我也不例外。我的感觉是，如果要深入了解Windows还是直接使用SDK比较好，对系统了解会更直接和透彻。如果你对编程是一般爱好，不是发烧友，或者只是因为收入比其他技术行业高些而作此行，或是公司要求，那么用MFC也无可厚非。有一点，据我所知，精通MFC，哪怕是大师都是进不了Microsoft的。Microsoft是使用SDK编写应用的，其他有名的公司也是如此,如Rational/Numega/Netscape/Real 等等。所以我建议，有兴趣的朋友在力所能及的情况下，可以使用SDK做点东西，可以让以后的饭碗更保险一点。
BTW,我完全不懂Linux/Unix,只是个Windows fan而已。

SendMessage和PostMessage的区别很是微妙。假如hwndRemote是其他进程的hwnd，并且它处理WM_QUIT的时候会用MessageBox确认一下，
那么，SendMessage(hwndRemote,WM_QUIT...) 将使自己死掉，直到“确认”为止
而PostMessage则使hwndRemote直接退出，没有任何机会去确认一下。
恩，就是PostQuitMessage()吧如果SendMessage是直接调用窗口的WindowProc，那么，相当于那个进程的WindowProc函数就跑到本进程的线程中运行了！想想真不可思义!

调试易

关于消息机制这个话题是很有意思的，希望继续探讨。

解决方案 »