Upon reader request, the OS/2 Museum is publishing the source code to the NT video miniport driver for VirtualBox. To recap, this is a NT video miniport which allows 32-bit NT versions to use high-resolution graphics modes in a VirtualBox VM. The miniport is unique(?) in that a single binary supports every released version from NT 3.1 through Windows 7 (Windows 8 no longer supports the same video miniport model).
The source code now lives in a private Mercurial repository. The credentials are ‘guest’/’guest’. The complete source code can be downloaded as a zip/gzip/bz2 archive from the above page. A floppy image with a driver binary produced from this source is also available for download.
The source code is published under the very liberal MIT license. Anyone can more or less use it as they see fit. However, if you fork it, please do not ask for help—you’re on your own.
The source code as such is quite straightforward. Anyone capable of reading C source code should have no trouble with it when combined with the NT DDK documentation.
DriverEntry() function detects the version of the video port by attempting initialization with successively smaller versions of the miniport initialization structure
VIDEO_HW_INITIALIZATION_DATA . This is then used to slightly adjust the behavior of the miniport at run-time. In theory it could be used to implement additional features not available in older NT versions.
One non-obvious aspect may be the code within
USE_GETACCESSRANGES preprocessor conditionals. This is code which uses the
VideoPortGetAccessRanges() video miniport function… which unfortunately does not exist in NT 3.1. It would be nice to use this function because it’d take care of PCI resource allocation but alas, that would make the driver fail on NT 3.1 because the function is statically imported. It would be possible to write reams of code that dig through internal NT structures and import
VideoPortGetAccessRanges() “manually” at run-time, but that was deemed far more trouble than it’s worth (although it would be an interesting exercise!).
The list of supported display resolutions is fairly arbitrary and currently includes common modes up to 2560×1600. Larger modes would be technically possible if one wanted to give old applications a heart attack, but probably would be of little use beyond the novelty value.
Building and Debugging
The code was written to build with the Open Watcom C/C++ compiler version 1.9 or later. The Open Watcom package does not require the Microsoft SDK or DDK in order to build the miniport (everything necessary is included). It is likely that the driver can be built on non-Windows hosts, but that was not tested.
It is possible to debug the miniport using WinDbg and get debug logging from
VideoDebugPrint(), although there’s another caveat—in old NT versions, only checked builds of the video port provided the routine, so a debug build of the miniport won’t run on regular “free” NT builds.
The makefile includes a
videomp.img target which copies the files intended for distribution into a subdirectory and then runs a mkimage utility to produce a floppy image. This utility is unfortunately not available at this point (but may be in the future), but it’s of course possible to copy the files onto a floppy (image) through other means as well.
For installing on NT 3.x, FRAMEBUF.DLL must be copied from the NT distribution media (this is the GDI display driver). Unfortunately this driver is not installed by default and different across the 3.x versions, so it is not feasible to distribute it together with the miniport (copyright issues aside). On NT 4 and later, FRAMEBUF.DLL is installed by default and no extra tweaking is needed. This is documented in the readme file.
The source code is not expected to be useful to more than a tiny handful of people. The driver binaries perhaps might. No significant enhancements are planned as the driver is currently doing its job quite well.