|Date:||June 13, 2006 / year-entry #197|
|Summary:||I don't mean to pick on this series of entries, but it illustrates an interesting pattern of stumbling across the wrong "solution". The series begins by attempting to trigger the system's monitor blank timeout by posting a message to the desktop window. As we saw earlier, the desktop window is a very special window and...|
I don't mean to pick on this series of entries, but it illustrates an interesting pattern of stumbling across the wrong "solution".
The series begins
by attempting to trigger the system's monitor blank timeout
by posting a message to the desktop window.
As we saw earlier,
the desktop window is a very special window
and as a rule
should be avoided, since it won't behave like windows created
In particular, the author tried to post a message to the desktop
This used to work in the
historically open world of the window manager,
but security and robustness concerns have come to take
priority over compatibility.
In Windows XP SP2, the desktop window resists being disabled
because programs were doing it inadvertently,
it appears that the desktop also resists having messages posted to it.
My guess is that this was done as a way to strengthen protection against
This did improve robustness and stability,
it also broke the article's dubious
Enter round three,
wherein the author fumbled around for other windows the
monitor blank timeout message could be posted to,
the author found that
posting the message to the mysterious window
I knew in the back of my mind that people developed software this way, but the hopeful part of my brain continued to wish that it was merely taking place in a fantasy world. Making up intentionally invalid parameters and seeing what happens falls into the category of malicious goofing around, not in the realm of software engineering and design. Even if you find something that seems to work, you certainly wouldn't design a product around it!
(Similarly, I've seen people ask questions like
"What does message 49251 mean?"
This is the reverse case: Seeing a made-up number and
attempting to assign meaning to it.
Message numbers starting at
If you look more carefully at what the author stumbled
across, you'll see that the "solution" is actually another bug.
It so happens that the numerical value
#define HWND_BROADCAST ((HWND)0xffff)
It so happens that internally, the window manager
For example, a presentation program might want to suppress monitor power-off when it is the foreground window by trapping the message and turning the monitor back on. If such a program happens to be running, broadcasting the power-off message to all top-level windows would turn off the monitor for all the windows that deferred to system default behavior, but when that presentation program received the message, it would turn the monitor back on. Now you're at the mercy of the order in which the windows process that broadcast message. When the presentation program processes the message, the monitor will turn back on, and if that program happens to be the last one to process the message (say, it got paged out and was slow to page back in), then the monitor will merely blink off and back on.
The correct solution is not to post messages to random windows. If you want the message to go through window message default processing, create a window and process it yourself. Don't try to trick some other window (or in this case, hundreds of other windows simultaneously) into doing it for you.
<-- Back to Old New Thing Archive Index