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.

Notice that I'm using floats instead of doubles in the new function,
mostly to be able to use struct wined3d_matrix and multiply_matrix().
At a rough estimate the precision should still be good enough.

While these won't be used by the shader, they potentially affect the
calculated offset for WINED3D_APPEND_ALIGNED_ELEMENT elements.

Instead of a fixed array of wined3d_shader_signature_element structures.
Shader model 4 shaders can have different semantics in a single
register, e.g.  v1.xy TEXCOORD0 and v1.zw TEXCOORD1, so having a single
wined3d_shader_signature_element structure per register isn't
necessarily sufficient.