video mode change under NT 4.0

[Federico Bianchi <bianchi at www dot arte dot unipi dot it>]

On Tue, 12 Oct 1999, Matt Lewandowsky wrote:

> 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?
....

Are you sure you can do a VESA call under NT 4.0? I have been using it
with either S3 or Matrox video cards, and the VESA INT 10h APIs are simply
not available in the VDM environment (not even when they are running full
screen). I made some experiments with DJGPP, a DOS graphics previewer and
a cute small program, INT.COM, which came with the Interrupt List
distribution. I actually didn't try DPMS APIs, nor I repeated the
experiment on SP4 or later (I'll do an INT 10h AX=4F01h either this
morning or tomorrow, just to keep on the safe side), but this was the
result.

Attaching and detaching a VDM is actually pretty easy, and might even be
reasonable if it worked properly to grab the protected mode API pointer).
As of 9x, this is actually a non-issue: the restrictions are much lazier,
and DPMI applications are quite more powerful.

Best regards
.... 
> -----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>
>