This is the mail archive of the
cygwin-xfree@sources.redhat.com
mailing list for the Cygwin project.
RE: Possible cause of Windows 98 failures?
- To: "Harold Hunt" <Harold at compasstechnologies dot com>, "Cygx \(E-mail\)" <cygwin-xfree at sources dot redhat dot com>
- Subject: RE: Possible cause of Windows 98 failures?
- From: "Suhaib Siddiqi" <ssiddiqi at inspirepharm dot com>
- Date: Fri, 29 Sep 2000 15:11:01 -0400
> 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:
The directx 7.0 dlls on Windows 2000 and Win Me/98 have different version
numbers.
Using DirectX 7.0 on Windows NT/2000 surface locks works ok, but on
Windows98 it fails. I am not sure what is going on, except the Win16Mutex
issue.
>
> "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.
Actually, you need to look into xf_dx.dll source code. The xwin/directx.c
contains only calls
to this xf_dx.dll. xf_dx.dll is the one which makes calls to DirectX on
your susyems.
Suhaib
> 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