Experiments with Windows 7 window management

[William Swanson]

Many people have strong opinions about client side window decorations.
I would like to introduce some facts. Specifically, how does Windows
7, a widely-used desktop OS with client-side decorations, handle
things?

Unresponsive applications:
I created a test program with a "crash" button and a standard border.
Pushing the button puts the application into an infinite loop. Once
this happens, the border becomes unresponsive to move and resize
actions. The window will not come to the foreground in response to
clicks, alt-tabbing, or taskbar switching. The context menu on the
taskbar button still works, although the close button has no immediate
effect. The OS detects the crashed state after about two seconds, and
places "(Not Responding)" in the window's title bar. The OS then greys
out the window contents once the user attempts any further
interactions. This zombie window responds to move and raise events,
but not resize attempts. Clicking the close button brings up the
force-quit dialog.

Slow applications:
I created a second test program to simulate slow response times. The
program sleeps for 20ms each time it receives a message, which adds up
quickly under the talkative win32 API. Dragging the title bar causes
the window position to change somewhere between 1-10 times per second,
depending on how far I move the mouse. Moving the mouse farther causes
the window to update more slowly. Resizing is even slower, taking
between 1-2 seconds per update. Expanding the window leaves unpainted
background clearly visible for about 3/4 second during updates. Even
so, there was enough visual feedback to move and resize the window to
within a few pixels of an on-screen target.

Debugged applications:
Halting a program in the debugger causes it to freeze in the same way
as a crashed application. The window does not come to the foreground,
and the border does not react to move and resize attempts. On the
other hand, the window "snaps" to its new position once the debugger
releases it. This is surprising. It seems like the OS is queuing drag
events for the window, even when those events involve moving outside
the window rectangle.

Consistency:
My Windows box currently has nine open applications based on at least
five different toolkits (XUL, native Win32, WPF, SWT, and GTK). All
but one (the Songbird media player) use the system-standard window
borders. One application (Firefox) modifies the standard border with
its own widgets. Another application (Visual Studio) has a floating
toolbox with a non-standard border.

API:
It only takes two steps to add a border to a window. First,
applications must pass the correct flags to the CreateWindow function,
such as WS_BORDER or WS_CAPTION. Secondly, applications must forward
unhanded window messages to the DefWindowProc function. That's it; the
client-side user32.dll library handles all the drawing and user
interaction. Applications are free to respond to message such as
WM_SIZE and WM_CLOSE, but doing so is not necessary. The DefWindowProc
provides default implementations for messages like these. The ease of
applying the standard border could explain its high level of
consistent usage.

Conclusion:
Hopefully these experiments throw some light into the client-side
window decoration discussions. I am not saying that Windows is right
or wrong; I am simply illustrating how it deals with some of the
issues mentioned on the mailing list. Lots of people use Windows every
day, so its approach can't be _too_ fundamentally broken.

-William