虽然网上已经有无数文章讲这个的，但是我还是被坑了（……

这丫返回WAIT_OBJECT_0+nCount的时候代表有新消息来了，但是并不是说GetMessage一下就行。

看起来好像是GetMessage然后啥啥啥就OK了，但是它返回的时候，消息队列中可能有超过一条的消息。正常情况的消息循环，是GetMessage的循环是吧，所以不存在这个问题。但是MsgWaitForMultipleObjects返回和GetMessage返回不同，MsgWaitForMultipleObjects返回的时候是说“有消息”但是没说有多少，而GetMessage返回的时候是获取了一条消息。

解决方法是用PeekMessage，它返回的时候有两种可能，一个是获取到消息了一个是没获取到消息。所以MsgWaitForMultipleObject返回的时候，要不断调用PeekMessage直到它拿不到消息位置，才算结束。

另：MFC下消息循环用的AfxGetThread()->PumpMessage();。注意返回值

然后就是窗体，窗体关闭的时候来个PostQuitMessage吧免得循环卡着了。

其实为什么会突然间想到这东西呢？在写窗口程序的时候，比如用到socket或者什么的，不是经常要等待吗。用异步+回调（消息）来做又很麻烦，用同步（阻塞）方式不用多线程的话又卡窗体。然后受到DoModal这种方法的启发，自己也来弄个内层消息循环，这样窗体就不会没响应。比如socket在等待连接、等待接收、等待发送这类时候，就可以用WSAEventSelect来代替select，然后等待事件的时候不就要用到MsgWaitForMultipleObjects了吗（望天望天

这是蛋疼的代码，就是利用socket发送接收文件而已，但是把select给弄成上述那样了……电脑上装的vc都是express版，就弄了个dwing大大做的vc6简化版然后自己配上了调试用的库，算是用上了mfc

9月9日更新：加入了出错判断，更改了发送端SOCKET的设置使之FIONBIO为真，防止send的时候出现可能的阻塞。接收端加入了FD_CONNECT和FD_READ成功与否的检测，READ的偷懒就算了说不是实际用途只是示例，但是FD_CONNECT的出错检测没有的话不小心先点了接收就会非常讨厌。