Windows can be pretty weird sometimes

Npl

Veteran
Just fumbling around with some of my likely-never-to-finish hobbiest projects and diving into the wonders of Win32 programming again.

It seems you can pretty much mess with any Window thats run from the same user account. Figure sending them a message to just kill the UI (in a rather kick-in-the-teeth way) - it works rather well closing every window including explorer.exe (eg the icons on your desktop and the start menu are gone). Code for doing this is rather simple:
Code:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>

// just there to automatically link with user32.dll (if using MS Compiler)
#pragma comment(lib, "User32.lib")

int main() {
	PostMessage(HWND_BROADCAST,WM_QUIT,0,0);
}

I know that a evil program can and should be able to do alot of damage on an open system (its very much the point of an open system that you are rather unrestricted in your own user-turf), but this this is effectively messing with other processes which shouldnt be allowed!

Pretty much every window program expects some order in the way the windows are closed, this violates it - leading to leaks and processes that still run without UI but were never expected to do so (cause usually there are other notifications if windows are closed)
 
shouldnt be totally unrestricted
but I can see the need for windows shutdown needing to close windows
Starting with Windows Vista, message posting is subject to UIPI. The thread of a process can post messages only to message queues of threads in processes of lesser or equal integrity level.
 
Hell, I can do the same thing in one line of batch script... Paste the following into a command-line prompt in a Windows OS and it will tank the box in the exact same way:

Code:
for /F "usebackq tokens=1 skip=3" %A in (`tasklist.exe`) do @taskkill -f -im "%A"

I don't really see the difference, TBH, between this and a fat kill statement in Unix. You're making effectively the same call...
 
shouldnt be totally unrestricted
but I can see the need for windows shutdown needing to close windows
Yeah I red that, means apps from Admins arent affected. And I agree that it should be possible to close Windows - just do so in a manner that doesnt violate the documented way things are supposed to run.

If you send such messages out-of-order you can seriously throw Applications off, they dont get closed per se - just 1 thread gets told to stop, while the rest of the program might not expect this to be the case.

This is just a very simple code-sample obviously, but you could do alot worse things if you know where an App allocates/deallocates or passes pointers around. You have your fingers directly in the message processing and no UIPI (Im running Win7) is protecting at all.
 
Hell, I can do the same thing in one line of batch script... Paste the following into a command-line prompt in a Windows OS and it will tank the box in the exact same way:

Code:
for /F "usebackq tokens=1 skip=3" %A in (`tasklist.exe`) do @taskkill -f -im "%A"

I don't really see the difference, TBH, between this and a fat kill statement in Unix. You're making effectively the same call...
Nope, this call just kills (or actually might not kill) the thread owning the UI - most Apps still run, crash or just behave odd (as this wasnt intended).
If it just where the same as closing all Windows then I wouldnt post this.
 
Ah yes, I see what you're doing. The QUIT broadcast is only respected by those programmers who decided to define that behavior, so really it's up to the developers who coded it wrongly if you run into that specific problem. It's a valid call to anything with a window handle...

Keep in mind that Microsoft did a generally bad job of getting developers to properly implement a true presentation layer (abstracted from the underlying process) until only recently; WPF is their answer to this dissociation and addresses a LOT of issues (to potentially include this one) so long as the developer is using those tools.
 
Ah yes, I see what you're doing. The QUIT broadcast is only respected by those programmers who decided to define that behavior, so really it's up to the developers who coded it wrongly if you run into that specific problem. It's a valid call to anything with a window handle...
Yes I just expected the system to handle these messages and not just pass them around verbatim. Makes your life quite a bit harder if every message could be bogus, every parameter could be nonsensical and you have no way to separate your messages from other processes.
eg. why would you ever have to send a WM_CREATE message, it should only appear upon creating the window (I did my allocations and pointer initializing there, would be pretty messy if you get another of these messages).
Sending other windows commands through the system via a seperate "SystemPleaseLetMeDoThis" function would be an easy enough option - sending messages directly (and the VERY SAME messages Windwos use internally) across Processes seems like some of the worst design decisions you could do.

Keep in mind that Microsoft did a generally bad job of getting developers to properly implement a true presentation layer (abstracted from the underlying process) until only recently; WPF is their answer to this dissociation and addresses a LOT of issues (to potentially include this one) so long as the developer is using those tools.
Seems more like an expensive band-aid for a truly bad design decision. And I managed to violently crash MS`own Apps via such broadcasts yesterday, amongst it IE8 and VC Express 10 which uses WPF (AFAIK).
 
Back
Top