Why do I have to return this goofy value for WM_DEVICECHANGE?
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? 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? 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. 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.
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.
Light
Dark
0 comments