Windows 9x Video Minidriver HD+ | Hacker News Reader

Windows 9x Video Minidriver HD+

os2museum.com

161 pointsingve39 comments

This is important work to make Windows 95 usable in VirtualBox!

As it stands, where possible, it's a better experience to use Windows NT 4.0 instead. Since it is more similar to modern Windows versions than Windows 9x is, it runs flawlessly in VirtualBox, yet it has that 1990's look and feel, and can run most Windows 9x software. But not all, alas.

Source code is here: https://www.os2museum.com/hg/boxv9x/ The credentials are ‘guest’/’guest’.

https://guest:guest@www.os2museum.com/hg/boxv9x/

The lack of good high-res drivers has been a pain whenever I wanted to run old versions of Windows in QEMU/virt-manager.

Will this work in there as well or is this a VirtualBox only driver?

You might consider 86Box. It's emulation rather than virtualization, but it supports a range of graphics cards. This makes it easier to use the default drivers and/or find other drivers online.

Another emulation option is Bochs. I haven't played with it in years though.

I think I've tried messing with that before but I couldn't get it to work right. It's an extremely accurate emulation of the hardware but that comes at the cost of performance and the stuff I wanted to mess with for nostalgic reasons didn't really need emulation that accurate.

Still solid options for anyone else looking into more accurate emulation of old machines, though, these two pieces of software can get keep that thirty year old piece of legacy software running for at least another decade or so!

PCem is probably the more suitable emulator if accuracy is not as important.

Has development of PCem restarted?

Yes. New maintainers.

Fun side note: Bochs has a working port on the PlayStation Portable (PSP). Booting up Windows 95 on my PSP in high school was my geeky party trick.

The BearWindows VESA driver (for 9x[1] and NT[2]) works well on QEMU. The last version of VBEMP that won’t nag you on each boot is G. Of course, that does nothing about the rather poor support for resolution independence on historical Windows, so 1280x1024 is about the largest practical resolution.

(Unfortunately, Sound Blaster 16 emulation is known to be broken in combination with the Gtk UI[3], so no / choppy sound for you, but things should work over SPICE. I’ve yet to find a SPICE client that will maintain a fixed 2:1 display scale with no interpolation.

A helpful HN user described[4] how to enable SMB1 on recent versions of Samba and so share files over something other than floppy images, TFTP, or active FTP. I haven’t found a better way to do this with QEMU’s native Samba integration than launching it, then finding the generated smb.conf somewhere in /tmp and patching it.)

[1] https://bearwindows.zcm.com.au/vbe9x.htm

[2] https://bearwindows.zcm.com.au/vbemp.htm

[3] https://gitlab.com/qemu-project/qemu/-/issues/469

[4] https://news.ycombinator.com/item?id=29260861

I've been real spoiled with the auto-resolution switching support with the QEMU guest agent and libvirt drivers and that becomes painfully obvious when I resize a Win2k/Win98 VM and scroll bars appear...

I haven't had much trouble with the virt-manager GUI in terms of sound. For Win2K I could install the server edition and remote into it over RDP if it ever becomes an issue.

I wrote a generic VESA framebuffer driver for Win9x a while back; it was surprisingly easy to get something working, as all it had to do was switch modes and then give the DIBENG the framebuffer to draw on. A few hundred lines of Asm were sufficient, most of it being the mode switch and configuration logic.

What I didn't do was give it a VxD, so windowed DOS boxes didn't fully work --- the architecture of 9x is a hypervisor and what isn't trapped/virtualised goes directly to the HW, so the DOS boxes end up messing the state of each other and the "system VM" where the GUI runs. Unfortunately I don't know of a way to have a similarly generic virtualisation of the hardware.

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

I feel like windows development is riddled with this sort of thing, undocumented secrets that you just have to figure out for yourself. I wonder if it's deliberate from 1980's Microsoft being paranoid about corporate espionage or something.

When I was at VMware in the 'aughts, VESA often saved us as an unaccelerated option for guests that didn't yet have a driver for our virtual display. Was there really no VESA driver for the 9x family? Or does QEMU's BIOS not do it or something?

BearWindows and SciTech Display Doctor are the two VESA drivers which come to mind for Windows 9x. If I remember correctly Bear will also work in 3.x.

I remember these being somewhat frustrating to get working with VirtualBox. I never tried with QEMU.

I've personally moved away from virtualization for older OSes and to emulation. It just seems much easier to deal with even if it's more resource intensive.

In Windows what advantage does 32-bit color give over 24-bit color? Does 32-bit have 11-11-10 bits per pixel instead of one byte each? From my limited experience with win32 programming I don't remember any API's that let programs specify colors with that much depth.

it is usually RGBX8888 or XRGB8888, 4 bytes per pixel makes a lot of math easier

So the last one isn't used, just padding for alignment. Got it.

The X byte of 32-bit color is nowadays used as the alpha channel (brightness), and is usually called A. But I'm not sure if Windows 95 supported alpha channels for display.

DirectDraw and Direct3D run on Windows 95 and both use alpha, so it's possible they could do something with it, but they also might just emulate it. It's been 27 years since I was writing video games for Windows 95 :p

9x GDI doesn't support the alpha functions that are in NT GDI, possibly due to memory constraints.

Win 9x family never did. Win NT family does

Hm, why screenshot resolution (1152×864) is different from 1920×1200, as it set in "Display Properties > Settings > Desktop area"?[0]

[0] https://www.os2museum.com/wp/wp-content/uploads/2022/06/boxv...

This is interesting because I have direct experience with this on real hardware recently. I have a GeForce 4 MX440 graphics card connected via DVI to a native 1920x1200 display. Windows 98 will let me set the native resolution, but if I move the mouse outside the bounds (maybe 1152x864?) the whole screen will "pan" with the cursor and wrap to the other side of the screen. It's almost like 98 can display 1920x1200 but can only interact with a subset of it. I thought it was just some strange driver limit or an issue with my hardware, but maybe it's a limit in the core of the OS.

That's probably something to do with the GPU driver. Win98 doesn't really have any intrinsic limit on display resolution beyond the 16-bit limit (32k in each dimension, although I suspect you'll run out of address space for the framebuffer first) --- I've personally used 98se on a CRT at 2048x1536.

Maybe Windows9x doesn't get along with non-4:3 aspect ratio screens?

An update in case anybody comes across this. I found you were correct and the issue was my graphics driver, an Nvidia Detonator driver in this case. I installed a Voodoo3 (AGP) with stock drivers and enabled native 1920x1200x32 resolution under Windows 98 SE with no panning. A little fuzzy over VGA, but usable!

if i remember correctly it's a feature of the driver, basically you can set resolution higher than what is supported by your screen and it will create a sort of virtual screen that is "mapped" to the real one via panning.

Probably the gpu/driver don't recognize the resolution as supported by your monitor. It's should be possible to override that and set a custom resolution but i don't remember how... Sorry.

My memory could be wrong here but I had a 20“ CRT which could output 2048x1536 with no panning.

It's in the comments:

    Michal Necasek says: 
    June 6, 2022 at 10:30 pm

    Sure, the screenshot is of a 1152×864 desktop, 
    showing the maximum resolution available in 
    the dialog. I didn’t see the point of wasting 
    space with so many boring pixels

They don't think that anyone was interested in a screenshot.

> It's in the comments:

I see.

JFTR, It seems like it was a reply[0] to my comment[1], but they don't think anybody would be interested in replies, so not enabled threaded comments in WordPress, which makes their replies not so clear connected to guests comments:)

[0] http://www.os2museum.com/wp/windows-9x-video-minidriver-hd/#...

[1] http://www.os2museum.com/wp/windows-9x-video-minidriver-hd/#...

[2] https://www.collectiveray.com/wordpress-threaded-comments

The 'apply' button is active so these are unapplied changes.

What I really want is good 3d acceleration on M1 windows vm’s from 98 to Win 7, like I currently have using parallels on Intel Mac.

(Okay, not quite. The 3d support seems to start at winxp. )

3D support on Win9x would be a wonderful thing in a virtual machine. I have a few 90s and early 00s computers hanging around that I keep functional to play some games from that era that just do not work on modern windows or in virtual machines.

I haven't tried it on a M1 Mac, but 86box does offer Voodoo emulation. You can even emulate dual Voodoo 2s in SLI! https://86box.readthedocs.io/en/latest/settings/display.html...

Ah yes, AllocCStoDSAlias. You could do some fun stuff with that API and its inverse, AllocDStoCSAlias (or PrestoChangoSelector).

If you run VirtualBox on an M1 Mac, does it run under Rosetta emulation?

Or does it not work at all?

Wow! That’s fantastic!

Reply on news.ycombinator.com