Good news and bad news...
Good I know exactly what you are trying to do
Bad I dunno how to do it either.
A problem is that beyond-VGA modes tend to be (graphics)
chipset-specific, especially when it comes to the hi-res text modes.
VESA may have helped standardised this, but otherwise you'd be using
something with intimate knowledge of the chipset to set the modes.
This may be:
- a TSR VESA driver
- a proprietary TSR
- a proprietary command non-resident line utility
- the capabilities of the app itself
For example, Quattro Pro 5 for DOS "knows" a variety of different
chipsets, so you'd choose the chipset you have and then Quattro Pro
would offer you the appropriate modes. Ironically, one of the best
hi-res text modes was on one of the lowest-end (Oak) chipsets!
For another example, your app may have no knowledge of screen text
modes whatsoever, allowing you to control these before the app is
launched. The app may then:
- reset the res back to 80 x 25 (bummer)
- run as 80 x 25 in the top half or left corner of the display
- size itself to the actual character space (yay!)
To do the above, you'd typically write a .BAT that does a "mode
sandwich", something like this...
@Echo Off
VMode 132 60
YourApp.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
VMode 80 25
...where "VMode" is a notional proprietary mode-changing tool that
came with ye olde graphic card, using thumb-suck syntax.
The obstacles to doing this in XP are as follows:
1) Direct hardware access is disallowed
This may or may not be a problem, given that even arbitrary
proprietary modes can generally be selected via a standard BIOS call
that XP can trap and emulate, without direct hardware access required
2) Pre-VESA modes are non-standard and bound to now-extinct chipsets
An app that "knows" contemporary chipsets may handle thosde chipsets
accurately, but you may find all of these (typically un-accelerated
ISA chipsets) are by now extinct. So there may be nothing that
matches the SVGA you have; guessing may or may not bring joy.
OTOH, post-VESA mileage may be better, as I expect Windows full-screen
emulation natively embraces the VESA function set
3) The app may reset the display mode when it runs
Bummer, as I mentioned earlier... you successfully get some VESA
hi-res text mode to be applied by the app's XP shortcut, only to find
the app either resets this back to 80 x 25, or assumes you are running
at that res and draws itself in the top corner of the display, leaving
the rest of the (true full-screen) display blank.
So a lot depends on how the DOS app is written, as much as everything
else. Maybe you can get XP itself to preset a full-screen mode, or
use a CLI tool to do so (perhaps via a .BAT), or get the application
itself to set its own res if it has the smarts to do so.
To emphasise for other readers: Full-screen console is *hugely*
different to running as a maximixed window...
- inbuilt SVGA character generator used, so OEM not ANSI fonts
- direct screen writes make for far faster graphics
- no font settings can be applied (uses native SVGA fonts)
This is why apps often look completely different when running
full-screen, right down to different extended characters!