Scorpion
In order to reject a device removal query request, we need to return a special value BROADCAST_QUERY_DENY, this value also has a strange value: 0x424D5144.
Why?
We have tried to follow the WM_QUERYENDSESSION message processing method, that is, if it returns TRUE, the operation continues, and if it returns FALSE, the operation fails. However, when we actually did it, we found that many programs would refuse the removal request of Plug and Play devices, because these programs were written for Windows 3.1, and the operating system at that time was not plug-and-play. Ready-to-use features. What is going on here?
But the developers who developed these programs think like this: Now that I have the Windows 3.1 SDK, I have checked all the messages and only processed the messages I am interested in. As for the rest I don’t need to care about, I can directly Return 0, so there is no need to call DefWindowProc. Indeed, the above method does work on Windows 3.1. The developers carefully read the SDK documentation and found that 5 to 6 messages require a non-zero return value, and they need to ensure that this non-zero value is returned. . Other messages return a value of 0.
Then when we added a new message that required a non-zero return value, these programs continued to return a zero value, which caused all device removal queries to fail.
Therefore, we changed the return value 0 used to express "cancel" to another value. To further ensure safety, we also decided not to set this value to 1, because we thought that there might be many programs that would simply return TRUE to all messages, so we don't want to repeatedly modify the development document.
In the end, we chose the strange value mentioned above.
to sum up
This is another example of trade off with developers. Stronger than Microsoft, it is not easy to deal with this kind of thing.