vbesvga.drv: a VESA BIOS Extensions driver for Windows 3.1

Why Windows 3.1 needed a VESA driver again

The display driver that shipped with Windows 3.1 was written for a world of VESA-compatible clones with a fixed set of modes. Cards from the last three decades do not fit that assumption, and the usual patching workarounds assume a 256-colour mode exists on the hardware. vbesvga.drv is a rewrite of the Windows 3.1 SVGA driver that drops the hardware-specific code and talks to the VESA BIOS Extensions of the card instead, so one driver covers whatever 8-bit, 16-bit, 24-bit or 32-bit modes the firmware advertises.

The audience is retro-computing enthusiasts who want old software running on new machines. The author states the reasons plainly: to show that Windows 3.1 can run in True Colour at Full HD, and because his AMD Radeon RX 5500 XT has no 256-colour modes, which made the older VESA Patch useless on his own card. The second reason is the more instructive one, since it explains why a generic VESA route was needed rather than another fixed-profile driver.

From the Video 7 driver to VESA BIOS Extensions

The code is based on the Video 7 SVGA driver included in the Win16 Driver Development Kit, with most of the hardware-specific parts removed and support for multi-byte pixels added. That starting point matters because it keeps the Windows 3.1 side of the contract intact: the driver still speaks the same interface Windows expects, but the mode handling now comes from the BIOS rather than from a list of known chipsets.

The project is titled around two binaries, vbesvga.drv and vddvbe.386. The first is the Windows 3.1 display driver, the second is the VDD used under Windows 9x, and the README describes the 9x support as decent rather than complete. The screenshots support that claim in a limited way. A Windows 98 Active Desktop session renders at 1920 by 1080 with 32-bit colour according to its own Display Properties dialog, and the Channel Bar and desktop work. That dialog, however, shows only the current setting and does not allow on-the-fly adjustments, which the README links to an open issue in the project tracker.

The parts in the source tree

The repository is written in assembly, and its top level shows how the pieces divide up. Two directories hold the drivers, one for the Windows 3.1 display driver and one for the 9x VDD, and a third, VBEGRAB, holds the 256-colour-capable DOS grabber that arrived later. Alongside them sit the DOS-side utilities, and the presence of an AUXSTACK.ASM file suggests the author handles the auxiliary device stack explicitly rather than delegating it.

A release-work directory and a series of beta tags indicate a deliberate build and packaging pipeline rather than a set of loose binaries dropped into a download folder. The three most recent tags are v1.0-beta2 on 2026-05-25, v1.0-beta3 on 2026-07-10 and v1.0-beta4 on 2026-07-25, so version 1.0 has been through four published betas and has not yet been cut as a stable release.

Checking modes before you start Windows

The most useful thing in the tree is the mode-listing utility. The README screenshots show a 50-row MS-DOS 6.20 prompt running VIDMODES.COM, and the output identifies the card by the strings a VBE implementation is required to publish: the vendor string reads "(C) 1988-2018, Advanced Micro Devices, Inc." and the product name reads "NAVI14" on an RX 5000-series card.

The DOS-side utilities are assembled from the following sources in the repository:

SETUP.ASM
VIDMODES.ASM
MODETEST.ASM
AUXCHECK.ASM
AUXSTACK.ASM

On a live DOS prompt the two commands the project documents by name are the mode lister and the DOS mode command:

VIDMODES.COM
mode

The mode command is worth a warning, because the README singles out resizing a windowed prompt with it as one of the operations that can freeze on some hardware. The README does not give a step-by-step installation procedure for the drivers themselves, so the practical route is the tagged source releases in this repository, with VIDMODES.COM used first to confirm what the card can do before Windows is involved at all.

Hardware that still misbehaves

Generic support does not mean uniform support, and the README is unusually direct about the exceptions. The NVIDIA GeForce 1050 GTX has issues with windowed DOS prompts, with potential freezes when the mode command changes the prompt size and font corruption when switching to full screen, and the same corruption appears on blue screens. The author assumes newer NVIDIA hardware behaves the same way, which is a reasonable expectation but not a tested claim. AMD Radeon RX 5000-series cards work perfectly according to the author, who develops on one. A single report describes a 386 Enhanced Mode boot failure with an RX 7000-series card, and the author is careful to say it is unclear whether the graphics hardware or another motherboard incompatibility caused it.

The clearest case is the Intel 810 chipset, whose integrated graphics crash back to DOS during boot and leave a blank screen. The advice there is not a workaround but a redirect: an official driver for that chipset exists and should be used instead. This is the sharpest limit on the project, and it applies to a chipset that was common in the machines many of these systems emulate.

How this differs from the VESA Patch and the stock grabber

The VESA Patch is the traditional way to get more out of an SVGA card under DOS and early Windows, and it works by intercepting the BIOS video interrupt and offering 256-colour VESA modes. The README explains why that path failed for the author: the Radeon RX 5500 XT has no 256-colour modes, so the patch had nothing to switch to. vbesvga.drv works at a different layer, replacing the display driver itself and using the full VBE mode list the card exposes, including the 16, 24 and 32-bit modes the patch never offers.

For DOS titles that specifically need 256 colours, the VBEGRAB directory provides a separate grabber. The README shows Rayman running in a windowed DOS prompt through it, and describes the result as a bit choppy but working. A second screenshot shows Rayman Designer running instead on the stock Windows 98 grabber, which is a useful reminder that the new grabber is an addition rather than a replacement for the path that already worked.

Maintenance, betas and the missing licence

The repository is not archived and the last push was on 2026-09-13, so work on the driver is still landing rather than being a frozen snapshot. The rate of that work is not high: four published betas of version 1.0 over the period from 2026-05-25 to 2026-07-25, and a gap between the most recent tag and the last push. Support is also structured around a deliberate process. Issue templates were added in November 2025, and the author asks reporters to fill in the questions in the format given rather than to replace them with freeform text, on the grounds that the missing fields are exactly the ones needed to diagnose a system.

One administrative detail is worth checking before you plan to redistribute anything. No licence identifier is set in the project metadata, so the terms under which the driver may be copied into a disk image or bundled with other software are not stated in the repository. That is a question for the author rather than something the documentation answers.

Editorial conclusion

Adopt vbesvga.drv if you run Windows 3.1 or 9x on VESA hardware and want a mode above 256 colours, and leave it alone if your machine relies on Intel 810 integrated graphics or if you need a clear redistribution licence. Before installing, run VIDMODES.COM on the target machine to confirm the card advertises the modes you want, and pin the exact v1.0 beta tag you test with, since the driver is still in beta and no licence identifier is set in the project metadata.

Frequently asked questions

Official sources

1. Issues
2. PluMGMK/vbesvga.drv on GitHub
3. README
4. Releases