在之前的一篇文章中，我曾提到：如果你希望拒绝一次设备移除查询请求，则需要返回一个特殊的 BROADCAST_QUERY_DENY 值，因为太多的程序开发者认为，他们已经覆盖了所有 Windows 消息的处理了，对于其他的消息，直接返回 0 就可以了。

从那时候开始，操作系统引入了很多新的消息，这些消息中的很大一部分都是在 DefWindowProc 中进行了默认的处理。
时不时的，我会碰到一些应用程序会这样假设：微软应该从来不会优化窗口管理器组件吧？对于那些我不需要处理的消息，我直接返回 0 就可以了，问题不大。

其实，这些应用程序甚至都没有处理所有现有的旧消息！

我们看一个例子，在一个应用程序中，它有一个帮助窗口，这个窗口会处理一些它感兴趣的消息，然后对于所有其他消息，它直接返回了 0。结果就是：用户连关机都关不了，因为应用程序对系统发出的广播消息 WM_QUERYENDSESSION 返回了一个 0，这意味着，应用程序对操作系统说：”等等，请不要关机”。

我猜这个应用程序的开发者会意味用户会在关机前先手动关闭他的应用程序吧。

另外，自定义键盘按钮（如音量控制按钮）也不起作用（如果焦点在此帮助程序窗口上），因为它忽略了将 WM_APPCOMMAND 消息传递给 DefWindowProc 函数。

因此，我再次恳求你：如果你不处理窗口过程中的消息，请将其传递给 DefWindowProc 函数。你的用户真的会谢。

另外有个小细节需要注意：如果你使用的是框架窗口，请遵循该框架的协议来指示你希望进行默认消息处理。例如，对话框过程不会将未经处理的消息传递给 DefWindowProc 函数。它们仅返回 FALSE 以指示应进行默认处理。

总结

我想这里作者的原则很简单：对于你不想处理的消息，不要处理并简单返回 0，而是交给系统默认处理函数 DefWindowProc。
否则，各种意外会发生。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《No, really, you need to pass all unhandled messages to DefWindowProc》