[Bug 2082] DirectDraw games only showing black screen

http://bugs.winehq.org/show_bug.cgi?id=2082

--- Comment #130 from Ken Thomases  ---
(In reply to comment #125)
> I think that Stefan was on the right path.  I think that, when ddraw/wined3d
> goes to set up window A for full-screen, it should not attempt to change the
> Win32 window.  I think it needs to work with the user driver to set up a
> full-screen OpenGL surface that's outside of the Win32 window hierarchy. 
> This surface would have to avoid interfering with mouse events.  Those
> should still be delivered to whatever Win32 window is under the cursor.

Another approach would be for ddraw to create a Win32 device window that can
actually go in front for DDSCL_FULLSCREEN.  As mentioned, it would have to
avoid interfering with mouse events.  I think that WS_EX_TRANSPARENT should
have that effect.  The docs are unclear but numerous sources on the net say
that's how WS_EX_TRANSPARENT works.  In Wine it seems to only work that way
when combined with WS_EX_LAYERED.  We would probably need tests to confirm how
it's supposed to work.

Besides handling WS_EX_TRANSPARENT correctly in user32 and the wineserver, the
user drivers might need to add special support for WS_EX_TRANSPARENT windows.

The problem with any approach that uses a Win32 window, though, is that it will
be visible and accessible to the game.  For example, the game might enumerate
all windows of the thread, encounter the device window, and get confused.  The
window is also vulnerable to window ordering.  For example, if WA does
SetWindowPos(dialog D, HWND_TOPMOST, ...) then the dialog will once again be in
front of the drawing.