Note: See also an updated version.
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.
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.
Late Update: Here’s a screenshot of Windows NT 3.1 running in 1152×864 resolution in true color:
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 😉
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?
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.
Awesome! Thanks Michal! 🙂
Yes, I’m still here – more’s the pity. 🙂
Could you do the miniport for Windows NT/9x with 4k resolution? I really need it.
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.
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 .
I expect that was a joke. If not, please consider yourself laughed at.
I want the resolution 4K 16:9 (3840×2160). Thank you for helping!
Is there a way I can add a new resolution?
Yes, either you ask me, or you build your own 🙂 I’ll add 3840×2160.
How can I build my miniport drivers to add new resolution with your source code? Thank you.
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.
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).
> 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?
Can you please add 1280×1024 and 1536×1024?
Yes. I could have sworn 1280×1024 was there already, but clearly not…
HEAVY NECRO alert!
No, 1280×1024 was never there. IIRC, you shared my distaste for non-4:3 resolutions at the time, so it was skipped in favour of 1280×960.
Addendum: see the third paragraph of http://www.os2museum.com/wp/nt-video-miniport-hd/
Erm… may I ask a favour, Michal? Can you roll this post into the previous one, so I don’t look so scatter-brained? 🙂
I added a link to the updated version.
Please let me know if that doesn’t do the trick (completely merging the old posts is something I’d prefer not to do).
Can you publish a screenshot of Windows NT 3.1 in 1024×768 32 bit color (True color) please?
I want to try it in VMWare and VBEMP still isn’t working, It’s working in NT 3.5x.
I would really rather not reconfigure my VM back and forth, but I added an 1152×864 True Color screenshot of NT 3.1.
Can you develop this driver also for VMWare please? (VMWare is faster from VirtualBox and more other advantages…)
Sorry, no. Someone else can do that.
1. It would be nice if it had the ability to automatically adjust the resolution when the VM’s window is resized.
2. It would be nice if it supported Direct2D and Direct3D acceleration.
Yes. Ponies and unicorns would be really nice too.
1. I guess your response means that someone else will have to do it?
2. I can’t get the latest source to compile with Open Watcom 1.9. Can you please make it able to be compiled with MinGW?
It means I have no interest in making such modifications at this time. But someone else can certainly take the code and run with it.
I also have zero interest in MinGW so I can’t help with that, sorry.
Can you fix the issue with it not compiling with Open Watcom 1.9.0?
Perhaps you could start by explaining precisely what the “issue” is? I don’t have a crystal ball, believe it or not.
Its an issue with the $< and $OBJS in the makefile. The $< results in no file name being used when it tries to compile using the .rc and the $OBJS results in it thinking that it equals BJS.obj.
It turned out that I was running nmake when I should’ve been running wmake. Running wmake in its source location results in it compiling with no errors.
I’m glad to hear that.
Can you add support for BMF_WINDOW_BLT to it? It helps speed up the drawing of windows when moving them around, etc.
What about getting it compiled with Visual Studio 2019?
Go for it. I have a feeling that getting it to produce something that old versions of NT can load might not be easy.
I cannot get it to output debug info in Windows Server 2003 and ReactOS even though I removed the # before the part of the makefile that adds the DBG switch to the list of flags to use when compiling it. Can you please fix it so it outputs when used in those two OSes?
Yes, but it could take me several years.
Why? Too busy with an actual job/life?
I’ve made a forum post about it. You can see it at https://forums.virtualbox.org/viewtopic.php?f=2&t=98613.
Wow. What pushy posters here. Just casually asking for DirectX acceleration. Sure, it’s that simple just to add it. Jeeze.
Hey Michal, whilst you’re at it, please can you write some NVIDIA RTX 3090 drivers and a DirectX gaming layer for OS/2? Should only take you a couple of hours. Thanks.
I compiled the latest driver source and modified NT3.x oemsetup.inf to include all supported video modes:
https://eternallybored.org/misc/virtualbox/boxvnt-af25f34dfa7a-hires.vfd
Now you can run NT 3.1 in 5k: https://eternallybored.org/imgs/compstuff/nt31_5k.png
(hint: use 64k colours, with True Color there are problems drawing the right half of the screen)
Cool! I really need to update my binaries, too. Did you try to analyze the limits where things start breaking down? I am not at all surprised that it would happen because there was nothing remotely that big in 1995.
Not really. I also tried 4096x2304x32, which has the same behaviour. I thought 64MB memory limit might be the problem (5k requires over 56MB just for the framebuffer), but even with updated bootloader the display behaves the same (OTOH, Paintbrush doesn’t cause crazy swapping when it opens in almost full-screen).
OK, I did a few more tests – things start breaking at 3840x2880x32, at lower resolutions (including 2560×1600) I haven’t noticed any problems.
I also updated the driver with a few more common resolutions (1600×900, 2560×1440), and included the source on the floppy image, since there’s more than enough space.
It would be nice to have it compiling under ReactOS Build Environment. Making that be possible will allow for it to be included with ReactOS (which would get rid of a “New Hardware Found” dialog box).
@Zero3K: And you know you were banned from any communication channel of the ReactOS project out of a reason. Main reason was that you stop haunting us and others you might see somehow fitting to us in your eyes.
We know about this driver, even without you haunting the author in his dreams. If we are ready to use it, we can fix it for Mingw-w64/MSVC build ourselves. There is ZERO(3k) need to demand such stuff from the author as he has his own plans and aims, as we do too.
@Michal Necasek, sorry for the mess…
No problem. I can ignore what deserves to be ignored.