NT Video Miniport for VirtualBox, With Source Code

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 boxvnt miniport in NT 3.50The 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.

Code Notes

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.

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

Installation

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.

Closing Remarks

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.

This entry was posted in Graphics, NT, Source code, VirtualBox. Bookmark the permalink.

15 Responses to NT Video Miniport for VirtualBox, With Source Code

  1. Darkstar says:

    That’s great news! Any chance that it’ll also work with VMware?

    Now all I need to be happy is a properly working graphics driver for Windows 3.x in VMware (the hacked SVGA driver floating around has problems with the network and fullscreen DOS boxes). But I don’t suppose that’ll happen anytime soon, I guess nobody is crazy enough to develop for the retarded Windows 3.x driver interface 😉

  2. bearwindows says:

    Some years ago I tried to write universal framebuf.dll replacement driver, so it could cache slow screen buffer reads as in linux and clones and also as in Windows 2000/XP and later when hardware acceleration slider is moved to left position. But I failed to do it and give my source code to ReactOS Team. Could you made such driver?

  3. Michal Necasek says:

    No, this one won’t work with VMware. It would probably not be too hard to adapt, but it’s not something I’m planning to do.

    Yes, a Windows 3.x driver would be nice, unfortunately the driver model is (as you say) retarded and there is no very good sample to start from, which means a LOT of work.

  4. God says:

    Awesome! Thanks Michal! 🙂

    Yes, I’m still here – more’s the pity. 🙂

  5. Dang Son says:

    Could you do the miniport for Windows NT/9x with 4k resolution? I really need it.

  6. Michal Necasek says:

    NT, yes if you tell me exactly what resolution(s) you want. 9x, that’s a completely different kettle of fish. No immediate plans for 9x support.

  7. Dibya says:

    Please can you add all mesa3D opens soare gfx extentions like opengl, vulkan included in the package plus directx support . Please make it as a extra extention for xp and higher. Really it is painful to have no 3D accelaration .

  8. Michal Necasek says:

    I expect that was a joke. If not, please consider yourself laughed at.

  9. Dang Son says:

    I want the resolution 4K 16:9 (3840×2160). Thank you for helping!

  10. Dang Son says:

    Is there a way I can add a new resolution?

  11. Michal Necasek says:

    Yes, either you ask me, or you build your own 🙂 I’ll add 3840×2160.

  12. Dang Son says:

    How can I build my miniport drivers to add new resolution with your source code? Thank you.

  13. Sean McDonough says:

    I wonder (mainly as a thought experiment), would it be possible to write a display driver capable of handling any arbitrary screen resolution (as in, one could type in any [horizontal # of pixels] × [vertical # of pixels] and have the driver automatically adjust to the new resolution)?

    Thinking about it, it’d probably require bypassing the Control Panel screen-resolution UI and writing a custom frontend to interface directly with the guts of the system, unless it could feed Control Panel a “Custom Resolution” mode to show in the list of supported video modes (in which case it would still require a separate UI for typing in the desired resolution), at which point selecting the “Custom Resolution” mode from the list and hitting the “Apply” button (for NT 3.x, where it won’t let you apply the selected mode without hitting the “Test” button first, there’d probably have to be some dummy routine to either do nothing or else bring up the test screen for some run-of-the-mill resolution upon hitting the “Test” button) could bring up the custom-resolution UI, prompting the user to type in a number of horizontal pixels and a number of vertical pixels, and only then adjusting the resolution…

    Like I said, (mostly) a thought experiment, but still quite curious nonetheless.

  14. Michal Necasek says:

    It’s pretty much as you say — it is possible, but not directly and requires extra work. Basically the OS is only prepared to handle a fixed list of resolutions. Whether that’s more for historical reasons or to reduce user confusion I don’t know. But no major OS I know of lets the user just pick any random resolution (within some plausible range), even though the graphics hardware is perfectly capable of it.

    So what you need is to somehow tell the low-level driver (video miniport in the NT case) which resolution to report, force the OS to query the available resolutions, and then set the new mode. That is what the VirtualBox GAs do when you resize the virtual screen, there’s always the corresponding resolution added to the list.

    You can’t just report an insane number of resolutions either because the OS is typically not prepared to handle it, and even if the low-level components could handle 100,000 resolutions, the UI would be unusable.

    Nowadays there are two completely opposite trends, for VMs users want any resolution they choose, yet hardware is all flat panels with fixed resolution and using any resolution that’s different from the panel is of limited usefulness (with analog monitors it was all a lot more fuzzy, in more than one sense).

  15. Sean McDonough says:

    > yet hardware is all flat panels with fixed resolution and using any resolution that’s different from the panel is of limited usefulness

    According to Wikipedia, that’s usually the case even when the horizontal and vertical resolution chosen are both integer divisors of the horizontal and vertical native resolution (for example, setting a 1280×960 LCD monitor to 640×480 resolution will usually still result in a blurry image, even though 640 is exactly half of 1280 and 480 is exactly half of 960, so theoretically the monitor should be able to display a sharp image by having each virtual pixel map to a 2×2 square of physical pixels).

    Also, would 4096×2160, 4096×2304, and 5120×2880 (4K 17:9, higher-res 4K 16:9, and 5K 16:9, respectively) be doable?

Leave a Reply

Your email address will not be published. Required fields are marked *