The video miniport driver for VirtualBox has been updated. The miniport now supports a much broader range of resolutions, up to 1920×1200. Color depths of 32, 24, 16, 15, and 8 bits per pixel are supported for all resolutions, although Windows typically filters out some of those.
The above screenshot shows Windows NT 3.50 running in 1680×1050 resolution (16:10 aspect ratio), providing an impressive amount of screen real estate.
The list of supported resolutions now includes many common resolutions with 4:3, 16:10, and 16:9 aspect ratios. Only modes with square pixels are supported; for that reason, 1280×1024 (5:4 aspect ratio) is not on the list. The 1080p full HD resolution (1920×1080) is now supported.
Most users should now be able to find a convenient display resolution which either fills the entire screen in full-screen mode or is just large enough to fit without scrolling when the VM runs in windowed mode.
The list of modes is now checked against the size of video memory assigned to a VM. For VRAM sizes of 8MB or less, some high resolution, high color depth modes will be unavailable.
Note that unlike all later versions, Windows NT 3.1 does not dynamically query available modes and is limited to modes explicitly listed in OEMSETUP.INF. The list currently includes 640×480, 800×600, 1024×768, and 1152×864 resolutions.
The installation procedure is unchanged since the earlier release; a floppy image is provided for easy installation. For NT 3.x, the appropriate FRAMEBUF.DLL (either compressed or uncompressed) must be copied onto the installation floppy image before installing or updating the miniport driver.
Great! You should add a NT & Windows history section to the menu.
It’s planned, but first I have to research and write something!
I noticed a problem in MS NT 3.51 using OS2 Presentation Manager For NT. When the PM Shell is launched the screen resolution is tried to change, but it keeps the same and there is distortion on the top of the screen. It does work under VGA Mode.
Before I spend any time on it, do you have any evidence that the PM add-on works with anything other than the VGA driver?
Actually, I tried NT 3.51 with the PM add-on and saw no problem. The PM desktop uses VGA mode (640x480x4bpp), but switching works fine here.
You need WinDOOM!!! which runs great on NT 3.5 … that said, I wish there was more mainstream games of the mid 1990’s that were open sourced to bring them to OS/2 or Win32 …
This driver is awesome. It even works flawless on Windows Neptune Build 5111. So far it also worked on anything else I threw at it. (NT-based, of course.)
Thanks a lot for that.
That says a lot about the initial video miniport design. Much better than any other Microsoft OS before or since 🙂 The two-component structure (miniport/display driver) works quite well, but these days it’s a lot more complicated with all the 3D stuff. The Windows 3.x display driver model looks insane in comparison.
Glad to know it’s working for you.
Any particular reason it only goes as high as 1920×1200? I, for some reason I cannot explain, have my heart set on 2048×1536 for 4:3 and 2560×1600 for 16:10.
Note: 1280×1024, I agree, was silly with it’s 5:4 aspect, but I recall a few cards back in the day (such as my Tseng Labs ET4000/W32p and my brother’s S3) offered 1280×960 resolution, which is 4:3.
No particular reason except lack of testing. Technically it should be doable. I’ll probably update the driver to support more resolutions, but no promises as to when.
I took a peek at the Windows 3.1x video driver samples in the DDK. All ASM and pretty convoluted. Yet, somehow vendors came out with slick drivers that supported hardware acceleration and could switch resolutions on the fly and such.
Whats interesting is the dates in the source comments. This stuff is from 1987 and makes references to OS/2 DOS boxes! The 8 plane Video 7 and 8514 drivers appear to actually be from the 3.x era.
Windows 2.0 was designed to run in the OS/2 1.x DOS box. The 8514 driver probably goes back to circa 1987 but the VGA stuff is partially even older, 1986 and possibly earlier.
The hardware vendors had resources to throw at the problem (or were forced to, take your pick). They also worked on the driver for a number of years before they got to the 1994-1995 state.
On the fly resolution switching didn’t really exist I believe, only more or less convincing approximations thereof. For many years, the standard was to reinstall video drivers in order to change the graphics resolution. Even NT 3.1 still worked that way, even though the miniport model was much more flexible.
Interestingly, the source code for this dates only to September 1987. They never bothered fixing the conflict between Windows and OS/2 mouse drivers. I wonder if it was too difficult.
Works on VirtualBox 5.1.26; great job! (Somewhat redundant for NT4 and 2k, because VirtualBox Guest Additions already provides essentially the same level of graphics enhancement and comes with VirtualBox, and very redundant for XP and later, which have excellent graphics in VirtualBox straight out of the box, but, for NT3.51 and earlier, it’s incredibly nice to have!)
🙂
To a large extent it was simply a coding challenge. Once I had something that worked on NT 3.1/3.5/3.51, could I make it work with later versions as well? Yes, I could, but it wasn’t entirely trivial.
Come to think of it, it might actually not be redundant for NT4 and newer; IIRC (I’ll have to double-check this when I get home), the highest resolution the Guest Additions driver supports is 1152×864, while yours goes all the way up to 1920×1200 (and is backwards-compatible with NT 3.x to boot).
Have you considered possibly offering this driver to the VirtualBox team?
Also, while we’re on the subject of VirtualBox display drivers for older versions of Windows, have you thought about possibly writing a better 9x display driver than the 16-colour, 640×400 one that users of 9x on VirtualBox are currently saddled with?
No pressure – mainly just curious (OK, and a little, or more than a little, bit hopeful :-P).
The VirtualBox GAs should support much higher resolutions than 1152×864 with NT4… I think the logic there may be a bit different and more VRAM may be required for a VM to offer a given resolution.
It’s 640×480. But yeah.
I thought about that, the problem is that the driver is considerably larger because there’s no miniport/display driver separation like in NT. Writing one from scratch is a lot of work and publishing modified MSFT sample code is not really kosher. The Win9x display minidriver is actually not huge but the sample is 100% nasty mixed 16-bit/32-bit assembly. It’s even worse with Windows 3.x (and OS/2 2.x) where the display driver is a giant blob of assembler code. It’s all doable, but a fair amount of work.
Actually, reading the Windows 98 DDK license (in the Win95 DDK I couldn’t even find anything) sounds like distributing modified sample code is OK even in source form. I’ll look into it, but I’m definitely not promising anything.
Ah, OK. :-/
Like I said, (mostly) just curious.
> I think the logic there may be a bit different and more VRAM may be required for a VM to offer a given resolution.
Not to pressure you or anything, but…
If VBGA requires more VRAM for a given resolution than your driver does, doesn’t that indicate that your driver is more efficient then the GA driver, and therefore might be useful for the VBox team to have?
(Like I said, no pressure! Just wondering!)
I think the GA driver likes to reserve a lot of off-screen memory, which is easy to fix by giving the VM more VRAM. The GA driver is a lot more advanced, and really the miniport driver I wrote was primarily intended for NT versions that the VirtualBox GAs do not support at all.
Pingback: NT video miniport UHD | OS/2 Museum