This is the mail archive of the cygwin-xfree@sourceware.cygnus.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: XFree under alien systems - the XF86Sup.sys approach and Windows NT


Well, AFAIK, only DOS Console apps are allowed to directly access video
hardware in NT. (And therefore change VESA modes.) I use a DPMS screen
saver that takes advantage of this "loophole" by running a DOS app that
essentially does a "mode co40" in full-screen mode and then performing
the VESA call. I'm not sure how helpful this is, but it's about all I
know about video in NT. (And still more than I wanted to know...) Just
out of curiosity, did the mentioned code run in Win 9x?

My $0.02,

Matt Lewandowsky

-----Original Message-----
From: Federico Bianchi [mailto:bianchi@www.arte.unipi.it]
Sent: Tuesday, October 05, 1999 6:32 AM
To: Suhaib Siddiqi
Cc: XFree86 over CygWin mailing list
Subject: XFree under alien systems - the XF86Sup.sys approach and
Windows NT

<SNIP>
I had a discussion thread with Suhaib a couple of months ago about both
the XFree86 port to Win32 and the XF86Sup.sys approach chosen for the
OS/2
one. I used (and modified) the files he gave me to work with two generic
drivers available under NT, i.e., PortIO.sys and MapMem.sys (the names
are
pretty explainatory: PortIO lets user mode apps perform IN and OUTs to
devices, while MapMem maps a chunk of physical memory into an app
virtual
space), but so far my test applications consistently give BSOD on an NT
4.0SP5, S3 equipped machine. I had a similar trouble at the end of 1997
(I had to access SVGA/VESA under the NT VDM/DPMI subsystem), and I found

it was due to the optimizations the NT display driver used when
switching
modes.
<SNIP>

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