RE: Possible cause of Windows 98 failures?

[Harold Hunt <Harold at compasstechnologies dot com>]

I've been investigating why Cygwin/XFree86 does not work on Windows 9X.  It
turns out that Xwin, at startup, obtains access to the memory buffer that is
being displayed on the screen; to do this you have to lock the frame buffer,
prohibiting other applications and the GDI from writing to the frame buffer
at the same time as your code.  Xwin locks the primary surface frame buffer
at startup and does not release it until shutdown.  GDI functions, on WinNT,
silently fail when the primary surface frame buffer is locked; the primary
surface is the buffer of what is currently being displayed on the screen.
However, on Windows 9X, locking the primary surface frame buffer causes the
Win16Mutex to be obtained, which freezes the GDI and USER code, as described
in the MSDN Library:

"Limit your application's activity while a surface is locked. While a
surface is locked, DirectDraw often holds the Win16Mutex (also known as the
Win16Lock) so that gaining access to surface memory can occur safely. The
Win16Mutex serializes access to GDI and USER dynamic-link libraries,
shutting down Windows for the duration between the IDirectDrawSurface7::Lock
and IDirectDrawSurface7::Unlock calls."

I can think of a couple possible ways to avoid a permanent lock of the
primary surface frame buffer:
1) Rewrite the X/Server graphics calls to use the GDI instead of a frame
buffer.  Difficulty: ?
2) Rewrite the X/Server graphics calls to use NT device driver and 98 device
driver graphics calls instead of a frame buffer.  Peter Busch has started
this, but he doesn't have time to work on it right now.  Difficulty: Not too
bad.
3) Rewrite the X/Server graphics calls to use DirectX graphics calls instead
of a frame buffer; lock the primary surface at the beginning of each
graphics call and unlock it at the end of each graphics call.  Difficulty: ?

I'm going to investigate #2 further since Peter has already setup the
framework for it.

Harold