TONT 41613 为什么我需要为WM_DEVICECHANGE返回一个怪怪的值？

万全之策应对历史债。

原文链接：https://blogs.msdn.microsoft.com/oldnewthing/20031205-00/?p=41613

To deny a device removal query, you must return the special value BROADCAST_QUERY_DENY, which has the curious value 0x424D5144. What’s the story behind that?

要拒绝一次设备移除请求，你必须给出一个特殊的返回BROADCAST_QUERY_DENY，其值为令人好奇的0x424D5144。这背后有什么故事呢？

Well, we first tried following the pattern set by WM_QUERYENDSESSION, where returning TRUE allows the operation to proceed and returning FALSE causes the operation to fail. But when we did this, we found that lots of programs were denying all Plug and Play removal requests – programs that were written for Windows 3.1 which didn’t have Plug and Play! How could this be?

一开始，我们为WM_QUERYENDSESSION消息设计了如下的模式：返回TRUE，则操作继续执行，返回FALSE则使操作失败。然而当我们这么设计后，我们发现有大量的应用程序拒绝了所有的即插即用设备移除请求——而这些程序都是为Windows 3.1设计的，那时候还没有即插即用这一说！为什么会这样呢？

These programs decided, “Well, I have the Windows 3.1 SDK right here in front of me and I looked at all the messages. The ones I care about, I handled, and for all the others, I will just return zero instead of calling DefWindowProc.” And they managed to get this to work in Windows 3.1 because they read the SDK carefully and found the five or six messages that require a nonzero return value and made sure to return that nonzero value. The rest got zero.

（原因是）这些程序（的开发者）认为，『我面对的是Windows 3.1的SDK，然后我分析了一下所有的消息。那些我在意的，就写具体流程处理它，至于其它那些统统返回0就好，不用去做调用DefWindowProc这么麻烦的事。』这些开发者设法让这种设计跑起来了，因为他们仔细度过了SDK文档，发现有五六个消息需要非0值的返回，并确保了这些消息不会返回0，剩下的拿到的就统统都是0了。

And then when we added a new message that required a nonzero return value (which DefWindowProc provided), these programs continued to return zero and caused all device removal queries to fail.

后来我们增加了新的消息，要求返回非0的值（由DefWindowProc提供），这些应用程序仍然返回0值，然后所有的设备移除请求就全都失败了。

So we had to change the “cancel” return value to something that wasn’t zero. To play it extra safe, we also made the “cancel” return value something other than 1, since we suspected that there would be lots of programs who were just returning TRUE to all messages and we didn’t want to have to rewrite the specification twice.

由此，我们不得不将『取消』的返回值设置成一个不是0的值。双重保险起见，我们让『取消』的返回值同时也不是1，因为我们观察到会有大堆的软件对任何消息都返回TRUE，我们可不想因此将相关规格重写第二遍。