蝎子
为了拒绝一个设备移除查询的请求，我们需要返回一个特殊的值BROADCAST_QUERY_DENY，这个值还有个奇怪的数值：0x424D5144。
为啥？
我们尝试过遵循WM_QUERYENDSESSION消息的处理方式，即如果返回TRUE则操作继续执行，如果返回FALSE则会导致操作失败。但是，当我们实际做的时候，发现有很多的程序会拒绝即插即用(Plug and Play)设备的移除请求，因为这些程序是为Windows 3.1编写的，那个时候的操作系统还没有即插即用的特性。这是怎么回事儿呢？
但是开发这些程序的开发人员是这样想的：现在我有Windows 3.1 SDK了，我查看了所有的消息，并仅仅处理了我所感兴趣的消息，至于剩下的我不需要关心的，我可以直接返回0，这样就不需要调用DefWindowProc了。的确，上面这种方法确实在Windows 3.1上奏效了，开发人员认真地阅读了SDK文档，他们发现，这其中有5到6个消息需要一个非0的返回值，并需要确保返回这个非0值。其他的消息则返回0值。
然后当我们添加新的需要非0返回值的消息后，这些程序继续返回了0值，导致了所有设备的移除查询都失败了。
于是，我们将用于表达”取消”的返回值0改成了其他的值。为了进一步确保安全，我们同时决定不将这个值设置为1，因为我们想到可能有很多程序会简单地对所有的消息返回TRUE，所以我们不希望重复地修改开发文档。
最终，我们选择了上面提到的那个奇怪的值。
总结
这，又是一个和开发者trade off的例子。强如微软，碰到这种事儿，处理起来也不容易。