http://www.os2museum.com/wp/windows-9x-video-minidriver-hd/ OS/2 Museum OS/2, vintage PC computing, and random musings [os2floppy] Skip to content * Home * About + Wanted List * OS/2 History + OS/2 Beginnings + OS/2 1.0 + OS/2 1.1 + OS/2 1.2 and 1.3 + OS/2 16-bit Server + OS/2 2.0 + OS/2 2.1 and 2.11 + OS/2 Warp + OS/2 Warp, PowerPC Edition + OS/2 Warp 4 + OS/2 Timeline + OS/2 Library o OS/2 1.x SDK o OS/2 1.x Programming o OS/2 2.0 Technical Library + OS/2 Videos, 1987 * DOS History + DOS Beginnings + DOS 1.0 and 1.1 + DOS 2.0 and 2.1 + DOS 3.0, 3.1, and 3.2 + DOS 3.3 + DOS 4.0 + DOS Library * NetWare History + NetWare Timeline + NetWare Library * Windows History + Windows Library * PC UNIX History + Solaris 2.1 for x86 - Compaq EGA Technical Reference Guide Windows 9x Video Minidriver HD+ Posted on June 6, 2022 by Michal Necasek The OS/2 Museum has made available the first version of a display driver disk for Windows 9x running on VirtualBox. The driver uses a linear framebuffer and supports 8/16/24/32bpp modes with resolutions up to 1920x1200 pixels (see more below). The driver is not accelerated but tends to be very speedy on modern hardware. [boxv9x-640x480]Windows 95 in a usable resolution I'd like to say that it was easy to adapt the existing Windows NT video miniport driver for Windows 9x... but of course it wasn't. The Windows 9x display driver model is completely different and has nothing in common with NT. The Windows 9x display driver has much more in common with Windows 3.1 (and 3.0 and 2.x) drivers, and it has clearly directly evolved from those older drivers. So what makes it a "minidriver"? A Windows 2.x/3.x display driver has to implement a very significant chunk of GDI. Bit blits, lines, text output. There is a lot of cases to handle and a great deal of complexity. To give some sense of the complexity, the Windows 3.1 DDK sample driver for Video 7 cards is about 1.6 MB (circa 60,000 lines) of assembler source code. And that's just for 8bpp displays. Windows 9x drivers still have to do all that. The difference is that Windows 95 introduced the "DIB Engine", a large library that implements more or less all of GDI and that the display driver can "punt" to. The minidriver has to set modes and implement various housekeeping tasks, but all drawing can be handled by the DIB Engine. The minidriver can implement what it can do better than the DIB Engine, but doesn't have to. The DIB Engine in Windows 95 (DIBENG.DLL) is very similar to the DIB Engine that Microsoft released in September 1994 as part of WinG (WINGDE.DLL). I do not know the exact timeline and history. The WinG DIB Engine was designed to draw to memory bitmaps using GDI. DIBENG.DLL does exactly the same thing, but takes the idea one step further by making the video framebuffer itself a memory bitmap, optionally using the VFlatD VxD to present a bank-switched graphics card as a linear framebuffer. The exact history of the WinG and Windows 95 DIB Engine is unclear. WinG was released in September 1994, when Windows 95 was already well underway. It is possible that the DIB Engine was planned for Windows 95 and repurposed for WinG--which also ran on Windows 3.1 and NT 3.5. Or perhaps the DIB Engine was first written for WinG and then adopted for Windows 95. Minidriver in C The OS/2 Museum Win9x minidriver is written almost completely in C (using Open Watcom C/C++), in part to show that not only it can be done, but it isn't even too difficult, and the code is significantly easier to understand than the all-assembly DDK sample code. Writing the driver in C was mildly challenging. The biggest challenge was the fact that the Windows 9x display driver is a 16-bit driver, which means it has to deal with segmentation. That's actually something which is easier to deal with in C, because the C compiler provides a lot more sanity checks than assembler can. A somewhat nastier problem was that although the Windows DDK documents all the functions which the driver needs to implement and the DIB Engine functions it can call, the DDK does not provide prototypes for those functions. Although the documentation does pretend to list the prototypes, it often omits return types, more or less always omits the calling convention, and sometimes is a bit sloppy with argument types. I spent a good deal of time trying to figure out why the CreateDIBPDevice function was failing. I kept looking for bugs in my initialization code, but in the end I discovered that even though CreateDIBPDevice is a 16-bit function, it returns a 32-bit value not in the DX:AX register pair but rather in the EAX register. The Windows 95 DDK completely fails to mention this non-obvious yet crucial detail; I found it "documented" in U.S. Patent 6,525,743. The driver also implements and calls a couple of undocumented functions. One of the functions it calls is AllocCStoDSAlias, which Microsoft's KB Article Q67165 admits is used in the Windows 3.0 DDK but says it "will not be supported in future versions of Windows". In reality it was of course supported all the way to Windows Me... Supported Resolutions While the Windows DDK sample drivers are all hardcoded to support a small set of resolutions, the OS/2 Museum minidriver is not. It restricts the smallest resolution to 640x480 but not much beyond that. The maximum allowed is 5,120x3,840 pixels, but that is entirely untested. The supplied .INF files sets up common resolutions up to 1,920x1,200 pixels, but users can edit the .INF file (or Registry) and add their own resolutions. Note that Windows 9x likely will have trouble if there are "too many" modes listed, and it is unknown what the highest resolution might be before funny things start happening. Installation The driver can be installed through the Display Properties dialog or through the Device Manager; the method used should not matter. The driver works on Windows 95, Windows 98, and Windows Me. No attempt has been made to discover how far back it might work with Windows 95 betas. This entry was posted in Development, VirtualBox, Watcom, Windows 95. Bookmark the permalink. - Compaq EGA Technical Reference Guide 10 Responses to Windows 9x Video Minidriver HD+ 1. [cf08] Darkstar says: June 6, 2022 at 6:32 pm Maybe you could have put the download link somewhere in the article; it's pretty hard to find otherwise. DL link: https://www.os2museum.com/files/boxv9x.img 2. [8f7d] Michal Necasek says: June 6, 2022 at 7:51 pm Yeah... I didn't mean to publish the article yet. I added a download link and it is not the one you found. 3. [cf08] Darkstar says: June 6, 2022 at 8:07 pm Okay, sorry, yeah I was confused a bit by the short post Feel free to remove the link in my post (or the whole post) if it's not correct anyway 4. [8f7d] Michal Necasek says: June 6, 2022 at 8:13 pm No problem. I fixed your link and removed the old disk image. 5. [4cd2] Javier says: June 6, 2022 at 9:09 pm Nice! Does this target the newer VMSVGA ? Or the older VirtualBox VGA device ? Also: No source? I had problems writing (using Open Watcom) a mixed 32/16 VxD that would be dynamically loadable from Win9x, since the watcom linker seems to put some attributes in the VXD/LE section headers that 9x didn't like. I'm curious to see if display VxDs are purely 16-bit (not subject to this problem), you found a workaround, or are using a different linker The VirtualBox mouse.drv I made for 16-bit Windows ( in Watcom too, see https://git.javispedro.com/cgit/vbmouse.git/about/ ) does load under 9x and actually works (if you do the manual installation via system.ini -- a testimony to all the craziness Win9x had to do in order to preserve binary compatibility with win16) . But just for fun I was considering making a native 32-bit 9x mouse miniport driver/vxd (in C). 6. [8f7d] Michal Necasek says: June 6, 2022 at 9:30 pm It targets the VirtualBox (bochs heritage) video device because it's super simple to program for. Basically VMSVGA would make the code more complicated with no upside. I will release the source code when it's cleaned up a bit. There is no VxD in this driver. The last time I worked on a VxD was twenty years ago and I think that was with Microsoft tools. I'm pretty sure others have written VxDs with Open Watcom but I have no direct experience. The minidriver is a 16-bit DLL, at least if you don't count all the 32-bit registers it uses here and there. Windows 9x is a very strange beast. It preserves compatibility with DOS and Windows 3.1 by being DOS and Windows 3.1 on steroids. There's a lot of 32-bit code in Win9x, but at the same time all the old 16-bit code is there too, and Windows can use either. As far as display drivers are concerned, the Windows 3.1 DDK documentation is quite useful because the Windows 95 DDK was clearly written for people who already knew how Windows 3.x drivers worked. 7. [4cd2] Javier says: June 6, 2022 at 10:17 pm Ah, interesting, since the win16 video drivers do have both the usermode DLL part as well as the 32-bit VxD part (for 386 windows). Mouse drivers were likewise also 16-bit DLLs in win16 , actually loaded by user.exe (and one could consider VKD/VMD as the "32-bit part of the mouse driver"). I am curious how does 9x do it without the 32-bit graphics part. I guess it just assumes a VGA card for stuff like DOS fullscreen window switching. I tried boxv9x / boxvmini.drv and it does work (also DOS boxes). Got stuck into a black screen when switching directly from VBEMP (which a full reboot fixed) , but that's already an improvement from the existing drivers. Thanks a lot! 8. [5485] app4soft says: June 6, 2022 at 10:25 pm On screenshot there is "Desktop area - 1920x1200 pixels", but screenshot image resolution is just only 1152x864 pixels ( https: //www.os2museum.com/wp/wp-content/uploads/2022/06/boxv9x.png ) Could be there placed screenshot in 1920x1200 pixels, as it set in "Desktop area" settings? 9. [8f7d] Michal Necasek says: June 6, 2022 at 10:29 pm Exactly, Microsoft supplied a VxD (VDD) with Windows 9x that handles fullscreen VGA support. Vendors could write a mini-VDD to support Super VGA. I don't see any point in that, since DOS stuff is not really going to work better under Win9x. The architecture all goes back to Windows/386 (1987). The "native" Windows drivers are 16-bit DLLs and the DOS compatibility/virtualization drivers are 32-bit VxDs. 10. [8f7d] Michal Necasek says: June 6, 2022 at 10:30 pm Sure, the screenshot is of a 1152x864 desktop, showing the maximum resolution available in the dialog. I didn't see the point of wasting space with so many boring pixels Leave a Reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. * Archives + June 2022 + May 2022 + April 2022 + March 2022 + February 2022 + January 2022 + December 2021 + November 2021 + October 2021 + September 2021 + August 2021 + July 2021 + June 2021 + May 2021 + April 2021 + March 2021 + February 2021 + January 2021 + December 2020 + November 2020 + October 2020 + September 2020 + August 2020 + July 2020 + June 2020 + May 2020 + April 2020 + March 2020 + February 2020 + January 2020 + December 2019 + November 2019 + October 2019 + September 2019 + August 2019 + July 2019 + June 2019 + May 2019 + April 2019 + March 2019 + February 2019 + January 2019 + December 2018 + November 2018 + October 2018 + August 2018 + July 2018 + June 2018 + May 2018 + April 2018 + March 2018 + February 2018 + January 2018 + December 2017 + November 2017 + October 2017 + August 2017 + July 2017 + June 2017 + May 2017 + April 2017 + March 2017 + February 2017 + January 2017 + December 2016 + November 2016 + October 2016 + September 2016 + August 2016 + July 2016 + June 2016 + May 2016 + April 2016 + March 2016 + February 2016 + January 2016 + December 2015 + November 2015 + October 2015 + September 2015 + August 2015 + July 2015 + June 2015 + May 2015 + April 2015 + March 2015 + February 2015 + January 2015 + December 2014 + November 2014 + October 2014 + September 2014 + August 2014 + July 2014 + June 2014 + May 2014 + April 2014 + March 2014 + February 2014 + January 2014 + December 2013 + November 2013 + October 2013 + September 2013 + August 2013 + July 2013 + June 2013 + May 2013 + April 2013 + March 2013 + February 2013 + January 2013 + December 2012 + November 2012 + October 2012 + September 2012 + August 2012 + July 2012 + June 2012 + May 2012 + April 2012 + March 2012 + February 2012 + January 2012 + December 2011 + November 2011 + October 2011 + September 2011 + August 2011 + July 2011 + June 2011 + May 2011 + April 2011 + March 2011 + January 2011 + November 2010 + October 2010 + August 2010 + July 2010 * Categories + 286 + 386 + 3Com + 3Dfx + 486 + 8086/8088 + Adaptec + AGP + AMD + AMD64 + Apple + Archiving + Assembler + ATi + BIOS + Books + Borland + BSD + Bugs + BusLogic + C + C&T + CD-ROM + Cirrus Logic + CompactFlash + Compaq + Compression + Conner + Corrections + CP/M + Creative Labs + Crystal Semi + Cyrix + DDR RAM + Debugging + DEC + Development + Digital Research + Documentation + DOS + DOS Extenders + Dream + E-mu + Editors + EISA + Ensoniq + ESDI + Ethernet + Fakes + Fixes + Floppies + Graphics + Hardware Hacks + I18N + IBM + IDE + Intel + Internet + Keyboard + Kryoflux + Kurzweil + LAN Manager + Legal + Linux + MCA + Microsoft + MIDI + NetWare + Networking + NeXTSTEP + NFS + Novell + NT + OS X + OS/2 + PC architecture + PC hardware + PC history + PC press + PCI + PCMCIA + Pentium + Pentium 4 + Pentium II + Pentium III + Pentium Pro + Plug and Play + PowerPC + Pre-release + PS/2 + QNX + Quantum + Random Thoughts + RDRAM + Roland + Ryzen + S3 + SCO + SCSI + Seagate + Security + Site Management + SMP + Software Hacks + Solaris + Sound + Sound Blaster + Source code + Standards + Storage + Supermicro + TCP/IP + ThinkPad + Trident + UltraSound + Uncategorized + Undocumented + UNIX + UnixWare + USB + VGA + VirtualBox + Virtualization + VLB + Watcom + Wave Blaster + Western Digital + Windows + Windows 95 + Windows XP + Wireless + WordStar + x86 + Xenix + Xeon + Yamaha OS/2 Museum Proudly powered by WordPress.