A few months ago, I developed a trivial video miniport for use in Windows NT virtual machines. The primary goal was to improve display speed and get past the 800×600, 16 color display mode which is the maximum Windows NT (up to an including Windows 2000) can handle out of the box on “modern” hardware. The miniport is designed to work with the synthetic SVGA “hardware” emulated by VirtualBox.
A secondary objective was to write the miniport in such a way that as many Windows NT versions could be supported with a single binary. That objective was fulfilled beyond expectations; the driver binary works with every x86 version of NT from the initial July 1993 release of Windows NT 3.1 up to and including Windows 7 released in October 2009. Windows 8 appears to drop the video miniport interface and thus cannot be supported.
A test version of the video miniport is provided as a floppy image. The miniport can be installed from any directory, but a floppy image is typically the most convenient method.
The miniport driver works together with the FRAMEBUF.DLL display driver shipped with Windows NT. That causes a minor complication: in Windows NT 4.0 and later, FRAMEBUF.DLL is always installed on the system, but in NT 3.x it’s not. I have not found a way for the NT 3.x OEMSETUP.INF file to install FRAMEBUF.DLL from a drive (directory) different from the miniport itself. The NT setup keeps asking for FRAMEBUF.DLL in drive A: (assuming floppy installation) and does not allow the user to point to the NT installation CD (typically in drive D:) instead. As a workaround, the file FRAMEBUF.DL_ must be copied from the \I386 directory on the installation CD to the miniport installation directory (floppy image). It may be uncompressed, but that isn’t necessary. Needless to say, the copy of FRAMEBUF.DLL installed together with the miniport must match the NT version.
If anyone knows how to circumvent the above limitation, I’ll appreciate any pointers.
Installation
Important: Read the above note about FRAMEBUF.DLL before installation!
The installation procedure depends on the Windows NT version. For Windows NT 3.1, the Setup application must be used. Start the Windows NT Setup application, select Options/Change System Settings… and in the Display drop-down box, select (at the very end of the list) Other.
NT will ask for the driver path; assuming that the floppy image is in drive A:, simply accept the default. Once the OEMSETUP.INF file is processed, select the desired display mode.
After changing the display mode, a reboot is required. To change the display mode, the same procedure must be used. The first time the miniport is selecgted, NT will copy the required files. Next time, the currently installed driver can be used and the installation medium is not required.
On Windows NT 3.5x, the installation is different. The Display applet in the Control Panel must be used, as the Windows NT Setup application no longer allows display selection.
In the Display applet, click on the Change Display Type… button and the again on the Change… button. In the Select Device dialog, click on Other….
Windows will again process the OEMSETUP.INF file and add a list of new display models to the dialog. Choose one of them and click Install. Windows will provide an option to restart the system automatically after copying the required files.
Changing the display mode is easier in Windows NT 3.5x and can be done in the Display applet.
In Windows NT 4.0 and later, the miniport isn’t necessary. The VirtualBox Guest Additions may be used to provide higher display resolutions. That said, there’s nothing preventing the same miniport to be used. Installation is roughly similar to NT 3.5x, but the display settings menu can be accessed simply by right clicking on the desktop, selecting Properties, and going to the Settings tab in the Display Properties dialog. On NT 4.0 and later, there’s no need to restart when subsequently changing the display mode.
Implementation and Technical Notes
The miniport is currently limited to resolutions up to 1024×768. That is simply an arbitrary implementation limitation to keep the list of supported display modes relatively short. There is no technical reason why much higher resolutions couldn’t be used; what Windows NT would make of them is another question. It’s likely that further resolutions will be added in the future.
Performance is surprisingly good when using the software rendering implemented in FRAMEBUF.DLL. There is therefore no plan to implement an accompanying display DLL. The reason why NT displays so much faster with the custom video miniport compared to the standard VGA miniport is simple: with 16-color VGA, the display memory is organized in a very non-straightforward way and nearly every video memory access must be trapped and emulated. With the custom miniport, the display memory organization is very straightforward and the guest OS can access it directly, with no performance penalty.
The miniport driver was developed with the Open Watcom compiler (the Microsoft DDK was not used, except as a documentation source) and debugged on a set of VirtualBox VMs using WinDbg.
Thanks a lot for this! I run Windows NT Server 3.51 in a VirtualBox VM, and was stuck with a 16 colour 800×600 display until now.
I’m interested to know how high you can go in terms of resolution—a widescreen NT 3.xx would be amazing!
On the VirtualBox side, the only “real” limit is the amount of available (emulated) video memory. On the NT miniport side, there’s no practical limit, but I don’t know what else might explode if really big resolutions are used. Only one way to find out I guess 🙂
Widescreen resolutions should also be possible. Again there’s no issue on the VirtualBox and miniport side, the question is what the GUI and apps will make of it. I’ll try to throw something together, but probably won’t be done before January.
Yep, XPDM is dead in Win8.
Yuhong, you certainly win the award for the least relevant comments. This blog post is all about display in old NT versions, especially NT 3.x, and all you have to talk about is Windows 8.
I was referring to this:
“Windows 8 appears to drop the video miniport interface and thus cannot be supported.”
@michaln: Yuhong is infamous on Raymond Chen’s blog for irrelevant comments.
I know. I’m just going to delete the way-off-topic ones.
Will you try to make them work with older versions of NT 3.1? How is it different from:
http://navozhdeniye.narod.ru/vbemp.htm
? I used VBEMP with NT 3.1 and 3.5 in VirutalBox and it worked okay (newer versions can use the driver from the VirtualBox Tools, so I prefer to use them), but they failed on 91/92 NT 3.1 builds.
VBEMP uses the VESA BIOS, which means it’s not specific to VirtualBox, but it is limited to the modes supported by the VESA BIOS and needs undocumented NT interfaces to work.
The Oct/Dec ’91 NT builds used a completely different display driver model similar to Windows 3.0, so those won’t work. I’ll see how far back I can make it work when I find some time.
Nice, do you also consider a generic video driver for Windows 3.00 Real and OS/2 1.x?
First off, this isn’t a generic driver. It’s specific to the virtual “hardware” emulated by VirtualBox.
I don’t have a Windows 3.0 DDK, so no, not considered that. I did consider an OS/2 1.x/2.x version, but so much effort is required that it’s currently on hold. A Windows 9x version is likely to happen before that, as that’s an order of magnitude easier.
Pingback: NT video miniport HD | OS/2 Museum
Thank you very much, it worked like a charm! 🙂
Many thanks from me as well. Works great!
Could you reconsidered the OS/2 1.x version?
If only OS/2 1.x was as simple as NT… I’m still considering it but currently can’t devote as much time to such project as it would require.
Have you considered opening up the source for this? It’d be interesting to see a real life example of a miniport driver.
Yes. See latest article.
You’re the best! 😉
Thank you!
Works with Virtualbox 5. Great job!
By “x86”, do you mean both x86-32 and x86-64, or are you referring specifically to x86-32 (as seems to, unfortunately, be somewhat common practice)?
Of course, that would only make a difference for XP64 Professional (given that I assume you have not gone to the bother of getting the driver signed by Microsoft), due to Vista/7 total driver signature enforcement (literally the only way of loading an unsigned driver in 64-bit Vista or later without modifying Windows system files is to force the system to boot in Test Mode, which only even exists to give driver developers something to develop and test drivers on so they can convince Microsoft to sign them) and to XP being the first version of Windows to even have an x86-64 version, but I’m still curious. (Given the near-total compatibility of x86-64 Windows with x86-32 applications, I’m guessing that you meant the former rather than the latter, but I just thought I’d make sure.)
When I say x86 I mean 32-bit. It is common practice because for decades, x86 did mean 32-bit. To me, x86-64 is the early and obsolete name of the AMD64 architecture (which, sadly, survived in Linux). As far as I know, Microsoft never used “x86-64” to refer to anything. They used “amd64” or “x64”. For Windows XP ISOs from Microsoft (MSDN), “x86” is quite unambiguously used to refer to the 32-bit versions, so I don’t think I’m confusing things by using the same terminology as the OS vendor.
For the reasons you list, I never bothered building a 64-bit version of the miniport because it’s just not worth the bother for the OSes (XP+) that work fine without it.
Ah, thanx. 🙂
(Personally, I prefer “x86-64” over “AMD64” or “x64”, because it indicates its membership in, and considerable backwards compatibility with earlier members of, the x86 family in a way the others don’t.)
How can I install this driver on a Windows XP virtual machine?
Pingback: NT video miniport UHD | OS/2 Museum