NT seems to allow partial access for programs to view the availability of the LFB but it seems to not allow direct access to the LFB. NOLFB is a TSR that prevents programs from using the LFB.

For instance, This means that for games based upon the Build engine will be unable to use LFB for higher resolutions and for speed. (Check out VBETEST to view the LFB resolutions supported by your video card.)

Full-Screen NTVDM allows access to certain video modes programmed into the Kernel by M$.

It's funny. I've noticed that NT4 is actually more compatible with some older Forgotten Realms games (for video modes) than 2000 is! XP seems to fix these issues. heh. Thanks M$.

Hitler wrote:

I want a320x200 resolution option so I can run GTA, and Blood in 3dfx mode (I dont have TR), since VESA modes dont work on my machine even with gldvesa or nolfb (I always get a distorted screen).

BTW, I have a radeon 7000 AGP 64mb

Ah, the resolution setting in Glidos doesn't control the resolution at which the game plays. It controls how much Glidos scales the output from the game.

The 3dfx versions of both GTA and Blood work with Glidos (well for most people). With Blood I don't think VESA is involved. With GTA, you need Glidos's VESA support.

I'm not sure what is going on here. What have you tried, and what happened when you tried it?

HunterZ wrote:

Okay, I have an important question that may focus the issue a bit:
When you run VESA apps in WinNT/2K/XP, does it actually use the video card's on-board VESA support at all? From what I understand, the NT family doesn't like to let anything access the hardware that directly. Is VESA an exception to this behaviour?

In a nutshell, you're right: no application touches the hardware directly in an NT-based OS. When you run a console application (probably a VDM) in full-screen mode, the OS passes control of the display to the vgasave device driver, a built-in driver provided by Microsoft. Vgasave intercepts all the requests involving video access from the VDM and takes care of passing them to the actual hardware, and this includes BIOS calls.

The problem is that vgasave must be able to "freeze" the screen and save its state if you press alt-enter to return to the Windows desktop, so it can restore the display when the app goes full-screen again. As you can imagine, vgasave doesn't know about *all* possible details about video modes, memory banks, hardware registers, etc. for all cards, so it can only let the application use certain modes and issue certain BIOS calls, so it can keep with what's going on at the video card.

Why then must NOLFB be used under the NT family?

The different versions of NT (NT/2K/XP) behave differently when VESA calls are involved, but something they have in common is that vgasave lets an application query for the available VESA modes and discover that LFB modes are supported by the BIOS, but it refuses to honor the requests for changing into one of those modes. NOLFB intercepts the queries inside the VDM, before they are seen by vgasave, and report back to the program that no LFB modes exist. If the game has some sort of fall-back that works with a banked mode, it can request such mode and vgasave will let this go through.

By the way, from my experience and some bits of scattered info from MS, I believe that Windows XP is far more "liberal" than Windows 2000, supporting more VESA modes inside a VDM. Unfortunately, I don't recall how NT behaves in this case.

Regards,

MajorGrubert wrote:

In a nutshell, you're right: no application touches the hardware directly in an NT-based OS. When you run a console application […]
Show full quote

In a nutshell, you're right: no application touches the hardware directly in an NT-based OS. When you run a console application (probably a VDM) in full-screen mode, the OS passes control of the display to the vgasave device driver, a built-in driver provided by Microsoft. Vgasave intercepts all the requests involving video access from the VDM and takes care of passing them to the actual hardware, and this includes BIOS calls.

The problem is that vgasave must be able to "freeze" the screen and save its state if you press alt-enter to return to the Windows desktop, so it can restore the display when the app goes full-screen again. As you can imagine, vgasave doesn't know about *all* possible details about video modes, memory banks, hardware registers, etc. for all cards, so it can only let the application use certain modes and issue certain BIOS calls, so it can keep with what's going on at the video card.

The different versions of NT (NT/2K/XP) behave differently when VESA calls are involved, but something they have in common is that vgasave lets an application query for the available VESA modes and discover that LFB modes are supported by the BIOS, but it refuses to honor the requests for changing into one of those modes. NOLFB intercepts the queries inside the VDM, before they are seen by vgasave, and report back to the program that no LFB modes exist. If the game has some sort of fall-back that works with a banked mode, it can request such mode and vgasave will let this go through.

By the way, from my experience and some bits of scattered info from MS, I believe that Windows XP is far more "liberal" than Windows 2000, supporting more VESA modes inside a VDM. Unfortunately, I don't recall how NT behaves in this case.

Regards,

This is the best explanation of this I have ever seen! 😀

F. A. Q., Snover.

Now, Grubert - Supposing someone made a program to handle the problem-causing LFB modes?
Said Ken Silverman about NOLFB,
"When DOS programs initialize the VESA 2.0 linear framebuffer mode, one of the steps (after the screen mode is set) is using DPMI function call (ax=0x800) to map video memory into a linear space. Under WinNT/2K/XP, this call always fails. I don't know why. My programs exit to DOS with this error message: "DPMI_mapPhysicalToLinear() failed!". "

The DPMI host in Windows NT/2K/XP does not support the DPMI 800h call because it compromises security.

My friend Stletto tells me there is a long discussion on this in teh moderators forum, but I am no moderator!

Sadly, Stiletto say: "I have not heard from Andrea Mazzolenni re: AdvanceCab recently. I think I shall go pester him with an email!"

Sounds like it would be cool if someone could write an enhanced vgasave module then...

HunterZ wrote:

Okay, I have an important question that may focus the issue a bit:
When you run VESA apps in WinNT/2K/XP, does it actually use the video card's on-board VESA support at all? From what I understand, the NT family doesn't like to let anything access the hardware that directly. Is VESA an exception to this behaviour? Why then must NOLFB be used under the NT family?

I'm not really sure about this one myself. I can tell you one thing though, locking up a game in NT that uses VESA spells major disaster. You can't multitask out of it for whatever reason... you have to do a cold boot on the box. That leads me to think that there's at least some direct I/O between the video card and the program.

Schadenfreude wrote:

The DPMI host in Windows NT/2K/XP does not support the DPMI 800h call because it compromises security.

Is there a LFB (with a form that would make sense to a DOS
program)? And is it mapped into linear address space? And is there a way in NT/2000/XP to find where its mapped?

Because if the answers to all those questions are "yes", then isn't it just a case of hooking DPMI 800h and returning the right value? Assuming one can hook DPMI interupts (never tried it).

Nicht Sehr Gut wrote:

Let's try this. Scitech has UniVBE v6.7 for DOS available at: http://www.scitechsoft.com/products/enterpris … ree_titles.html […]
Show full quote

Let's try this. Scitech has UniVBE v6.7 for DOS available at:
http://www.scitechsoft.com/products/enterpris … ree_titles.html

Download and install that. In whatever directory you place it, it will contain these files:
README.TXT
UNICENTR.EXE
UNIVBE.EXE
UVCONFIG.EXE
VBETEST.EXE

Start up a command line and run VBETEST and try out some of the various video tests. If it locks up, Ctrl-Alt-Delete, then kill ("End Task") the command prompt.

Also, you might try going to:
http://www.bootdisk.com/bootdisk.htm
and grabbing the Windows 98 OEM bootdisk file. You just stick a blank floppy in your drive and double-click the boot98.exe to create a Win98 bootdisk. Delete the Drvspace.bin file off of the floppy and copy the VBETEST.EXE file from your UniVBE directory.

Now boot from that floppy and run VBETEST. I'm willing to bet that you will find that some tests pass that would not under XP.

OK, I've downloaded both files and tryed them out.
The results:

Win98 OEM Bootdisk:

All modes worked

WinXP

Only 8,16 and 32 bit per pixel modes had options listed.
640x480x16 or 32 800x600x16 or 32 1024x768x16 or 32
Linear Frame buffer: Quits without error on all selectable modes
Banked Frame Buffer: 90% distortion on all selectable modes, but had not crashed.

Schadenfreude wrote:

Now, Grubert - Supposing someone made a program to handle the problem-causing LFB modes? Said Ken Silverman about NOLFB, "When D […]
Show full quote

Now, Grubert - Supposing someone made a program to handle the problem-causing LFB modes?
Said Ken Silverman about NOLFB,
"When DOS programs initialize the VESA 2.0 linear framebuffer mode, one of the steps (after the screen mode is set) is using DPMI function call (ax=0x800) to map video memory into a linear space. Under WinNT/2K/XP, this call always fails. I don't know why. My programs exit to DOS with this error message: "DPMI_mapPhysicalToLinear() failed!". "

The DPMI host in Windows NT/2K/XP does not support the DPMI 800h call because it compromises security.

Originally posted by HunterZ
Sounds like it would be cool if someone could write an enhanced vgasave module then...

I also believe that it's a matter of implementing the correct handling for the DPMI call, but I fear that this *must* be handled inside vgasave or at least by some other driver working close to it.
Vgasave handles video hardware access when an application is running full-screen, this is somehow documented by MS. When the user hits Alt-Enter and switch back to the desktop, it's up to vgasave to save the screen state in order to restore it later. So handling the DPMI call is not enough, someone must save and restore the contents of the frame buffer and other hardware details (such as I/O registers). I have no idea if these details are hardware dependent, but they could be since the VESA standard only defines the BIOS calls, not the internal details for the cards. This would add extra complexity to vgasave, and one of the ideas behind it is to be hardware-independet. Remember that vgasave also works as a standard video driver when you boot into safe mode or when the current video driver fails to load (e.g., if you change your video card).

Originally posted by Glidos Is there a LFB (with a form that would make sense to a DOS program)? And is it mapped into linear ad […]
Show full quote

Originally posted by Glidos
Is there a LFB (with a form that would make sense to a DOS
program)? And is it mapped into linear address space? And is there a way in NT/2000/XP to find where its mapped?

Because if the answers to all those questions are "yes", then isn't it just a case of hooking DPMI 800h and returning the right value? Assuming one can hook DPMI interupts (never tried it).

I know very little about DPMI programming, but I bet you can only hook this call through a device driver, and you have to worry about the kernel internals for memory allocation. Doesn't look like an easy job.

Regards,

Snover wrote:

I'm not really sure about this one myself. I can tell you one thing though, locking up a game in NT that uses VESA spells major disaster. You can't multitask out of it for whatever reason... you have to do a cold boot on the box. That leads me to think that there's at least some direct I/O between the video card and the program.

I can only tell from my experience, but this seems to be one of the gray areas inside NT-based OSes. Problably some BIOS calls or I/O instructions are passed to the card when they shouldn't, leading, as you say, to a major disaster. I had to cold boot Windows 2000 several times while trying to run The Pandora Directive, because the game tries to switch into some video mode that is not supported. Meanwhile, there is a report in another thread (see showthread.php?s=&threadid=1326) about this game running under XP, so I take this as evidence that these systems handle VESA calls in different ways.

MajorGrubert wrote:

I also believe that it's a matter of implementing the correct handling for the DPMI call, but I fear that this *must* be handled inside vgasave or at least by some other driver working close to it.
Vgasave handles video hardware access when an application is running full-screen, this is somehow documented by MS. When the user hits Alt-Enter and switch back to the desktop, it's up to vgasave to save the screen state in order to restore it later. So handling the DPMI call is not enough, someone must save and restore the contents of the frame buffer and other hardware details (such as I/O registers). I have no idea if these details are hardware dependent, but they could be since the VESA standard only defines the BIOS calls, not the internal details for the cards. This would add extra complexity to vgasave, and one of the ideas behind it is to be hardware-independet. Remember that vgasave also works as a standard video driver when you boot into safe mode or when the current video driver fails to load (e.g., if you change your video card).

I know very little about DPMI programming, but I bet you can only hook this call through a device driver, and you have to worry about the kernel internals for memory allocation. Doesn't look like an easy job.

Hm... disassemble disassemble vgasave... too bad SaPu won't want to do this one! (and Microsoft would probably even further dislike that we do it!)

Where you learn of Vgasave? Google calls up miscellaneous... it's some sort of video fallback failsafe driver, if regulr video drivers don't work proper?

I hope some lurker programmer thinks on this! (Vlad...? Paul...?) If not, then maybe some video wizard like Andrea of AdvanceMAME! (But he dislike windows programming! *sigh*)

It's a holy Grail!

Originally posted by Unregistered OK, I've downloaded both files and tryed them out.
The results: Win98 OEM Bootdisk: All modes worked

Kind of figured that.

WinXP Only 8,16 and 32 bit per pixel modes had options listed. 640x480x16 or 32 800x600x16 or 32 1024x768x16 or 32 Linear Frame […]
Show full quote

WinXP
Only 8,16 and 32 bit per pixel modes had options listed.
640x480x16 or 32 800x600x16 or 32 1024x768x16 or 32
Linear Frame buffer: Quits without error on all selectable modes
Banked Frame Buffer: 90% distortion on all selectable modes, but had not crashed.

Very, very bad. Other than setting up a dual boot with Win9x or replacing your video card, I don't know what to tell you. That's terrible VESA/XP support. Even the GeForce4 will at least let you choose 640x480.

Have you tried the demo for "Extreme Assault"?:
http://www.bluebyte.net/eng/product...ssault/demo.htm

It runs a series of video tests before it chooses a "best mode" (based on your responses). If you can't run this in VESA mode, it should at least run in 320x200 mode. However, if you're like the other recent unlucky ATI guy, it might declare all video modes to be bad. Be aware that the demo is 12 Megabytes.

The 3dfx version of it should run with GliDOS.

Nicht Sehr Gut wrote:

Kind of figured that. Very, very bad. Other than setting up a dual boot with Win9x or replacing your video card, I don't know w […]
Show full quote

Kind of figured that.
Very, very bad. Other than setting up a dual boot with Win9x or replacing your video card, I don't know what to tell you. That's terrible VESA/XP support. Even the GeForce4 will at least let you choose 640x480.

Have you tried the demo for "Extreme Assault"?:
http://www.bluebyte.net/eng/product...ssault/demo.htm

It runs a series of video tests before it chooses a "best mode" (based on your responses). If you can't run this in VESA mode, it should at least run in 320x200 mode. However, if you're like the other recent unlucky ATI guy, it might declare all video modes to be bad. Be aware that the demo is 12 Megabytes.

The 3dfx version of it should run with GliDOS.

I tried it. I can already get vesa modes to work on all of my DOS games, but only with a banked frame buffer and thats always distorted

BTW, I'm "Hitler" I just forgot to change my name on those "Unregistered"s

Schadenfreude wrote:

Hm... disassemble disassemble vgasave... too bad SaPu won't want to do this one! (and Microsoft would probably even further dislike that we do it!)

I believe that vgasave probably works very close to the kernel, so it's probably something close to impossible to understand if you don't know a lot of details in the kernel.

Where you learn of Vgasave? Google calls up miscellaneous... it's some sort of video fallback failsafe driver, if regulr video drivers don't work proper?

This is the primary job of vgasave: to work as a regular video driver if the appropriate one fails. Imagine that your video card fails and you install a different one: the old driver probably won't load, since it will not recognize the new card, so vgasave is loaded and you get standard VGA resolution (remember that a VGA card is the minimal requirement for NT).
Besides this, I once had access to some docs about developing NT device drivers that mentioned vgasave as the responsible for full screen console applications. However, I don't believe MS would let you write a replacement for vgasave, since it's considered part of the OS.

I hope some lurker programmer thinks on this! (Vlad...? Paul...?) If not, then maybe some video wizard like Andrea of AdvanceMA […]
Show full quote

I hope some lurker programmer thinks on this! (Vlad...? Paul...?) If not, then maybe some video wizard like Andrea of AdvanceMAME! (But he dislike windows programming! *sigh*)

It's a holy Grail!

You're right. Now, if MS could gently make some big chunks of Windows source code available...

UPDATE: Since Schadenfreude mentioned Google, I went after some recent info on vgasave, then I remembered that the real driver file is actually called "vga.sys" (vgasave is the service name in the registry), and found some interesting info on MSDN about video miniport drivers (http://msdn.microsoft.com/library/en-us/graph … vmport_7a1z.asp). Reading carefully it looks like there is an option for the driver developer to rely on the system provided driver for full screen operation or to write its own vga or svga driver.
Maybe we should bug the card manufacturers about this (my notebook at work has a nonvga-compatible driver, which means that the standard Windows vga driver takes care of full screen VDMs). It is possible, as stated in http://msdn.microsoft.com/library/en-us/graph … vmport_8nfr.asp.

Regards,

Was looking through MSDN today:

NTVDM 16-Bit Program Does Not Run If the Window Does Not Have FocusPSS ID Number: 812681 […]
Show full quote

NTVDM 16-Bit Program Does Not Run If the Window Does Not Have FocusPSS ID Number: 812681

Article Last Modified on 1/28/2003

--------------------------------------------------------------------------------
The information in this article applies to:

Microsoft Windows XP Professional
Microsoft Windows XP Home Edition
Microsoft Windows XP Home Edition SP1
Microsoft Windows XP Professional SP1

--------------------------------------------------------------------------------

SYMPTOMS
Many MS-DOS-based Video Electronics Standard Association (VESA) games start in windowed mode and call VESA BIOS functions to switch to SVGA mode. Because the Virtual DOS Machine (NTVDM) does not emulate VESA BIOS calls, such game programs had to start in full-screen mode in the past. Users had to manually switch to full-screen mode and then start the game. To better manage this behavior, NTVDM was enhanced to detect when a program calls a VESA BIOS function, and to automatically switch to full-screen mode to run the BIOS function without emulation.

However, if a program is started without focus and the program calls a VESA BIOS function, NTVDM cannot switch to full-screen mode to let the VESA BIOS handle the request. Instead, NTVDM waits for the window to have focus to make the switch.
CAUSE

In full-screen mode, programs have full access to the video hardware and do not run under emulation. NTVDM does not emulate VESA BIOS function calls in windowed mode or in full-screen mode. Therefore, if a program calls VESA BIOS functions in windowed mode, the program receives an error. If a program calls VESA BIOS functions in full-screen mode, the call succeeds if VESA hardware and software are present.

The problem occurs if a program is started without focus and a VESA BIOS function is called. In this case, NTVDM cannot switch to full-screen mode to let the VESA BIOS handle the request. NTVDM waits for the window to gain focus.
RESOLUTION
Programs must have the window focus before they can make VESA BIOS function calls.
Keywords: kbprb KB812681
Technology: kbWinXPHome kbWinXPHomeSearch kbWinXPHomeSP1 kbWinXPPro kbWinXPProSearch kbWinXPProSP1 kbWinXPSearch

This is stuff we already know but there it is for future reference and for proof. 😀

So if VESA access is fully there why the LFB troubles? Is it really DPMI? I'll see if I can find any programs check for LFB and that do not use protected mode just to verify.....

Also what about non VESA modes? Are these emulated? According to the above document there is no emulation whatsoever...if so then why the difference in video compatibility in DOS games in NT4/2K/XP on the same computer? Kernel? Can we confirm with MS?

For instance in 2K/XP after using a program that uses VESA and then returning to the desktop I experience desktop corruption. Only fix is to reset my display. Perhaps MS should program something in to refresh the buffer after exit from VESA?

From the Windows DDK:

Full-Screen VDMs in x86-based Machines For performance reasons, when the user switches an MS-DOS application to full-screen mode […]
Show full quote

Full-Screen VDMs in x86-based Machines
For performance reasons, when the user switches an MS-DOS application to full-screen mode in an x86-based machine, the display driver yields control of the adapter. The system VGA or a VGA-compatible miniport driver then hooks out from the V86 emulator all I/O instructions, such as application-issued IN, REP INSB/INSW/INSD, OUT, and REP OUTSB/OUTSW/OUTSD instructions, to the video I/O ports. These hooked I/O operations are forwarded to the VGA-compatible miniport driver's SvgaHwIoPortXxx functions.

However, for faster performance, a miniport driver can call VideoPortSetTrappedEmulatorPorts to allow some I/O ports to be accessed directly by the application. The miniport driver continues to hook other I/O ports with its SvgaHwIoPortXxx to validate the application-issued instruction stream to those ports.

To prevent a full-screen application from issuing a sequence of instructions that might hang the machine, the SvgaHwIoPortXxx functions monitor the application instruction stream to a driver-determined set of adapter registers. A miniport driver must enable direct access only to I/O ports that are completely safe. For example, ports for the sequencer and miscellaneous output registers should always be hooked by the V86 emulator and trapped to the miniport driver-supplied SvgaHwIoPortXxx functions for validation.

Direct access to I/O ports for the application is determined by the IOPM (named for the x86 I/O permission map) that the VGA-compatible miniport driver sets by calling VideoPortSetTrappedEmulatorPorts. Note that the miniport driver can adjust the IOPM by calling this function to have access ranges, describing I/O ports, released for direct access by the application or retrapped to an SvgaHwIoPortXxx function. The current IOPM determines which ports can be accessed directly by the application and which remain hooked by the V86 emulator and trapped to an SvgaHwIoPortXxx function for validation.

By default, all I/O ports set up in such a miniport driver's emulator access ranges array are trapped to the corresponding SvgaHwIoPortXxx function. However, VGA-compatible miniport drivers usually call VideoPortSetTrappedEmulatorPorts on receipt of an IOCTL_VIDEO_ENABLE_VDM request to reset the IOPM for the VDM to allow direct access to some of these I/O ports. Usually, such a driver allows direct access to all video adapter registers except the VGA sequencer registers and the miscellaneous output register, plus any SVGA adapter-specific registers that the driver writer has determined should always be validated by an SvgaHwIoPortXxx function.

DosFreak wrote:

This is stuff we already know but there it is for future reference and for proof. 😀

So if VESA access is fully there why the LFB troubles? Is it really DPMI? I'll see if I can find any programs check for LFB and that do not use protected mode just to verify.....

I think there is more than one problem: first you need to call the BIOS to get the appropriate mode, and this depends on vga.sys, then you need to map the frame buffer using DPMI, and you need some help from ntvdm.exe to make this happen (my guess).

Also what about non VESA modes? Are these emulated? According to the above document there is no emulation whatsoever...if so then why the difference in video compatibility in DOS games in NT4/2K/XP on the same computer? Kernel? Can we confirm with MS?

No emulation involved, but all low-level activities (BIOS calls, I/O instructions) must pass through vga.sys for validation. From my experience, NT 4, 2K and XP have noticeable differences in vga.sys.

For instance in 2K/XP after using a program that uses VESA and then returning to the desktop I experience desktop corruption. Only fix is to reset my display. Perhaps MS should program something in to refresh the buffer after exit from VESA?

Probably because some I/O registers from your card are reconfigured by the VESA calls and the display driver is not aware of what happened, or maybe the driver is somehow sloppy and doesn't bring the card into a known state before Windows redraws the desktop. This behaviour is probably driver-dependent.

Regards,

DosFreak wrote:

To prevent a full-screen application from issuing a sequence of instructions that might hang the machine, the SvgaHwIoPortXxx functions monitor the application instruction stream to a driver-determined set of adapter registers. A miniport driver must enable direct access only to I/O ports that are completely safe. For example, ports for the sequencer and miscellaneous output registers should always be hooked by the V86 emulator and trapped to the miniport driver-supplied SvgaHwIoPortXxx functions for validation.

T'ch, so much for this actually happening. I wonder if it's nVidia's fault. Hmm..

Very interesting stuff!

I know there are interested lurkers watching! (I hope Vlad is, and Paul...!)

We hijacked thread, though! Should it be grepped out?

Let's keep stabbing at this! I'd love to have a completely technical description of the problem for someone!

Originally posted by Schadenfreude We hijacked thread, though! Should it be grepped out?

Well, it's actually related. It's all about VESA in NT, which apparently is his problem.

Let's keep stabbing at this!

...and when you've fixed it, I have some lead here that needs transforming into gold (no "Tomb Raider" references please...already been done in another thread).

In all seriousness, I get the impression it would be easier to enhance existing SVGA PC emulation support.