Windows can be pretty weird sometimes

Discussion in 'PC Hardware, Software and Displays' started by Npl, Jan 12, 2011.

  1. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    7
    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)
     
  2. Davros

    Legend

    Joined:
    Jun 7, 2004
    Messages:
    16,826
    Likes Received:
    4,129
    shouldnt be totally unrestricted
    but I can see the need for windows shutdown needing to close windows
     
  3. Albuquerque

    Albuquerque Red-headed step child
    Veteran

    Joined:
    Jun 17, 2004
    Messages:
    3,880
    Likes Received:
    380
    Location:
    35.1415,-90.056
    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...
     
  4. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    7
    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.
     
  5. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    7
    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.
     
  6. Albuquerque

    Albuquerque Red-headed step child
    Veteran

    Joined:
    Jun 17, 2004
    Messages:
    3,880
    Likes Received:
    380
    Location:
    35.1415,-90.056
    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.
     
  7. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    7
    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.

    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).
     
  8. Albuquerque

    Albuquerque Red-headed step child
    Veteran

    Joined:
    Jun 17, 2004
    Messages:
    3,880
    Likes Received:
    380
    Location:
    35.1415,-90.056
    LOL, somehow that doesn't surprise me ;)
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...