This is the mail archive of the cygwin-xfree@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Possible cause of Windows 98 failures?



> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]