Who else likes it when this happens on Windows XP?

Post Reply New Topic

I've known about that trick for a long time, I used to have to do it quite often. I also knew about the taskbar counting as a "window" since a friend of mine had really thick lime green window borders on his Win2k box several years back, and it applied to his taskbar as well.

Now, I wonder, since you can still have windows open when explorer.exe isn't running, what does Windows use as its window manager? I know Linux is really modular in that you can mix and match different window managers, compositors, and other components of a desktop environment.

The whole windows framework is built into the OS, and on top of that MS provide a set of libraries that contain GUI controls like buttons, text boxes, lists, treeviews etc, and the fact that all windows app use these controls (they should, but they don't, but most do) means that all windows apps look and feel the same. Not only that but as MS keep compatibility if you run your app on Windows 3.1 it looks like a 3.1 app, run it on Win95 and it looks Win95, on Vista etc and it looks vista.

This idea of compatibility is one of the reaons why MS wants to keep control of its GUI. When jQuery releases a new version if you use it your websites will break, but a windows app always looks like a windows app as MS understands compatibility. If they looked to third parties to supply their GUI implementations then it's almost certain that apps will only work on the specific OS they were written for, and when Windows updates half your apps will stop working at all.

There is a KDE on Windows initiative, if you want to check that out. https://community.kde.org/Windows
However, it's much more supported on Linux, and I find that it's a resource hog compared to other desktop environments like Xfce.

I actually ran Xfce on Windows once through Cygwin (or maybe MinGW, I forget) and it was dog slow.

Yes, it can happen on Windows 7 if you aren't using the Aero theme.

If any of you are curious as to why this happens, then this is why. GUI (Graphical User Interface) programs are event driven, which means that there's a routine in the program that's constantly waiting for something to happen (like the user mousing over something, dragging the window, resizing, etc.). When an event happens, the program calls a function to deal with that event. There's an event in particular called WM_PAINT which a program receives when a part of its window has been uncovered or exposed. When this happens, the program is supposed to redraw the part of its window that was uncovered. However, if the program is really slow or frozen, it can't redraw its window in time, so what was drawn to the screen there is simply left there. In this case, my Firefox window, which was maximized and frozen, didn't redraw itself, whatever Task Manager had drawn to the screen was just left there when I moved the window around, leaving these trails.

Windows Vista and higher include a compositor called DWM (Desktop Window Manager), which is a program that handles all of the fancy Aero effects and transparency. When DWM is enabled, the windows no longer draw directly to the screen, but instead draw to some area of memory. The DWM then takes all of these offscreen buffers, and then puts them together (composites them) into the image you see on screen. If you're using the Basic or Classic theme on Windows Vista or 7, then the window drawing works just like XP and earlier, and this effect can happen. On Windows 8 and higher, there's no way to disable DWM, so this would never happen on those operating systems.