OS X doesn't have the same concept of maximized windows as Windows does.
There's no mode that prevents a normally-movable window from being moved.  If
a window is "zoomed", it mostly fills the screen but the user can still move
or resize it, at which point it ceases to be in the zoomed state.  So, users
are confused and frustrated when they can't move a window that's maximized.

To get similar behavior while still respecting Win32 semantics, we detect when
the user tries to move a maximized window.  When they start, a request is
submitted to the app to restore the window.  Unless and until the window is
restored, we don't actually allow the window to move.

The user expects to move the window from its current (maximized) position.  It
should not jump to its normal position upon being restored.  So, we set the
window's normal position to its current position before restoring it.

OS X doesn't have the same concept of maximized windows as Windows does.
There's no mode that prevents a normally-resizable window from being resized.
If a window is "zoomed", it mostly fills the screen but the user can still
move or resize it, at which point it ceases to be in the zoomed state.  So,
users are confused and frustrated when they can't resize a window that's
maximized.

To get similar behavior while still respecting Win32 semantics, we now let the
user try to resize maximized windows.  (The resize cursors are shown at the
edges of the window frame.)  When they start, a request is submitted to the app
to restore the window.  Unless and until the window is restored, we don't
actually allow the window to change its size.

The user expects to resize the window from its current (maximized) position.
It should not jump to its normal position upon being restored.  So, we set the
window's normal position to its current position before restoring it.

Modified version of patch by Erik van Pienbroek.

Modified version of patch by Erik van Pienbroek.

Based on behavior of Windows revealed by interactive tests added by Bruno Jesus.