Sending a window a WM_DESTROY is like prank calling pretending to be the police

http://blogs.msdn.com/b/oldnewthing/archive/2011/09/26/10216420.aspx

by mootothemax • 15 years ago

42 30 15 years ago

blogs.msdn.com

molo_8• 15 years ago

Wow, thanks for exposing me to how braindamaged win32 really is.

mattmanser• 15 years ago

I'm sure every operating system has weird quirks like this.

The odd thing about this article is it tries to pretend it's the user's fault. Which is doubly odd as Raymond Chen's stuff is usually pretty good.

molo_8• 15 years ago

This is more than just a quirk. Lets go through the bogons here:

1. Signal system confuses notifications with commands

2. API ties windows to threads

3. System allows you to send WM_DESTROY from one thread to another even though it provides undefined behavior

4. DestroyWindow() can only be called from a particular thread (related to item #2)

5. The API doesn't detect that the window has been destroyed as far as the application is concerned (whatever happens in ForgetWorkerThread() or PostQuitMessage(), the window actually goes away) without a DestroyWindow() call.

In short, WTF.

[edit: format]

amalcon• 15 years ago

Doing this is more-or-less like calling a signal handler directly in a UNIX program: you're not likely to get the result you want.

Lagged2Death• 15 years ago

Wow, thanks for exposing me to how braindamaged win32 really is.

To be perfectly fair, this arrangement (which I don't like either) is actually inherited from the Windows 3 API (Win16) and very likely goes back all the way to Windows 1.

orochimaru• 15 years ago

Irrespective of the article and its crux, the analogy is plain weird. Maybe he had a particular aspect of a prank call in mind, but it's tough to relate to.

oozcitak• 15 years ago

Then WM_DESTROY should have been called NM_DESTROY, since it is clearly a notification message not a command. The user is not wholly innocent here, but the Windows API team should be blamed for the misleading naming as well.

roel_v5• 15 years ago

No, because the NM_ messages are for standard controls only. There are more messages in the WM_ family that aren't really 'command' messages, but more 'notification' messages, like WM_CREATE. It's not like one can create a window by allocating memory, casting to an HWND and sending WM_CREATE to it.

I guess the conclusion is that one cannot blindly take WM_xxx message and think 'oh I can use ::SendMessage() and friends to make windows do certain things'. Only the documented behavior are valid use cases.

I guess one could say that the WM_xxx message should've been split up into more subclasses, but where to draw the line? I'm quite fine with using WM_xxx for all the fundamental window manager messages, as long as one minds their documented behavior there is no problem. (I realize that this last sentence can spark a whole discussion by itself on how far self-documenting a 'sane' API should be, but that's rather subjective imo).

jxcole• 15 years ago

I disagree with you and I think the grandparent is right. Even though the handle based architecture of the wind32 system is not object oriented, it was meant to have some object oriented features. If you think about this system as one in which a window handle is a window object and a message to that window represents a function call, then the WM_CLOSE is a public method that anyone can call. WM_DESTROY, on the other hand, would be a protected method that can only be evoked by the window system. Even though they decided that the overhead of a full OO system was too much, they still could have made the intention more clear by doing something like this:

WM_PUBLIC_CREATE and WM_PROTECTED_DESTROY

Then there would be no confusion about who was supposed to send the messages and how they were meant to be interpreted. Of course they don't have to use this exact terminology, but you get the idea.

raganwald• 15 years ago

This is a very good example of the kind of thing I see in all sorts of frameworks, where someone (often me) is trying to do something that isn’t 100% plain vanilla, and TheOneTrueRightWayToDoThis isn’t obvious. Our hapless programmer thinks of something, tries it, it appears to work, and they move along. Meanwhile, it only appears to work “by coïncidence," and in reality there is a hidden bug waiting to bite.

The ideal situation is to do more research and really understand how the leaky abstraction actually works, but there is never enough time in the day and deadlines in the calendar are closer than they appear...

fferen• 15 years ago

Haha, this happens to me a lot when learning new libraries or frameworks. My current solution is to just search StackOverflow with what I'm trying to do. Often, the Right Way is posted as a snippet, but even if there are no directly pertinent answers, related ones can also give insight on other things I'm doing wrong.

rbanffy• 15 years ago

> This thread creates an invisible window whose job is to do something until it is destroyed

Is this a common pattern? Why?

Wouldn't it be simpler to just create a thread or separate process without an attached window?

Sending a window a WM_DESTROY is like prank calling pretending to be the police

Related Stories