Why do I have to return this goofy value for WM_DEVICECHANGE?

Date:December 5, 2003 / year-entry #151
Tags:history
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20031205-00/?p=41613
Comments:    12
Summary: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,...

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.

Comments (12)
  1. Curt Hagenlocher says:
    December 5, 2003 at 2:55 pm

    Yes, but what does "DQMB" mean? Device Query Message Broadcast? Or should the 0x51 have been a 0x55 instead?

  2. Mike Dimmick says:
    December 5, 2003 at 3:04 pm

    Normally, MS ’embedded ASCII’ codes should be read from least- to most-significant byte, so in this case it’s BMQD, which I assume is Broadcast Message Query Deny.

    Other ones I can recall are the special structured exception codes used by Visual C++’s C++ exception handling (0xE06D7363, or E0 followed by "msc") and the equivalent in the CLR: 0xE0434F4D = 0xE0 + "COM".

    There’s another magic number in the C++ exception handling tables that appears to be the date that the programmer worked on it: 1993mmdd (I can’t find the reference at the moment).

  3. evariste says:
    December 6, 2003 at 3:56 pm

    Raymond, why is it that when you hover over a folder to get its size in a tooltip, the routine doing the calculating doesn’t seem to give up and say "larger than n gb" in a consistent manner? Sometimes it gives up after only 4 gb, sometimes it counts 11 gb then gives up…

  4. Raymond Chen says:
    December 6, 2003 at 8:05 pm

    I don’t know.

  5. Jordan Russell says:
    December 6, 2003 at 10:17 pm

    evariste: I would guess that it stops after a certain number of seconds have passed.

  6. Elias Fotinis says:
    December 7, 2003 at 7:28 pm

    You’re right, Jordan. Explorer only scans the folder for a maximum of 2-3 seconds and gives up with an incomplete result if it runs out of time. However, since the directory structure is cached, you can get incremental results by bringing up the tooltip again and again until everything is counted. A lazy man’s Properties box, I guess :)

  7. C# fan says:
    December 7, 2003 at 7:47 pm

    Raymond, if you have a little time, see this issue with the PostQuitMessage/WM_DESTROY here: http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=92812
    thanks

  8. Raymond Chen says:
    December 7, 2003 at 9:58 pm

    Yes it would have been nice to forward drops, but the problem is that there is no way to forward a drop to another window. To forward the drop, you’d have to get the IDropTarget of the window you want to forward to, but there is no way to get it. (You can attach an IDropTarget to a window via RegisterDragDrop but you can’t query the drop target from a window.)

  9. Mike Dimmick says:
    December 8, 2003 at 5:28 am

    Well, surely some piece of Windows knows, otherwise how would OLE know to call the IDropTarget methods when something is dragged over the window?

    Kraig Brockschmidt in Inside OLE (available in the Jan 2001 MSDN I have on my hard disk) says that RegisterDragDrop sets a window property with SetWindowProp – I think he means SetProp. I suspect, however, that this will only make sense in the context of the window’s process – it’s probably a local object pointer rather than a marshalled interface, and OLE is making an internal cross-process call to perform the appropriate work.

    I don’t see a reason why a feature couldn’t have been added to OLE to proxy the drop, though. I suppose everyone would have started proxying everyone else’s drops, given the general tendency of developers to try to steal other programs’ events…

  10. Moi says:
    December 9, 2003 at 9:02 am

    Rymond, what question was your 12/07/2003 6:58 PM post answering? Am I not seeing all the comments, here, or what?

  11. Raymond Chen says:
    December 9, 2003 at 10:23 am

    Hm, I was answering a question about why you can’t drop on a taskbar button, but I don’t see the source comment either. Odd.

  12. The Old New Thing says:
    April 25, 2006 at 10:00 am

    If you don’t, all sorts of bad things happen.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index