As promised, here is the source code for the Windows 9x VirtualBox display minidriver. For discussion of the source code, see the included readdev.txt file.
The code was developed on a Windows 10 host system. For extra credit, I attempted to build the minidriver on Windows 9x. Ideally with source code control… but is that even possible?
I could not find any clear information on whether Mercurial ever worked on Windows 9x. After a longish software archaeology session, I concluded that it did, at least somewhat. Here’s the proof:
I used a Mercurial 1.1.2 installer downloaded from here. As far as I can tell, none of the downloads from the official site (Mercurial 1.4 and later) work on Win9x—Mercurial installs without complaints, but fails to do anything useful, possibly because of Python incompatibility with Windows 9x.
But Mercurial 1.1.2 works, least on Windows 98 SE and Windows Me. It fails to clone over HTTP on plain Windows 95 because the Python socket module won’t load. There may be a way to upgrade the Windows 95 socket support but that is of limited interest to me given that Windows 98 SE works without tweaking. I have not tried to figure out if and how well other Mercurial versions work, since 1.1.2 did the job I needed.
With the source code on a Windows 98 machine, it’s no problem building it with the Open Watcom C/C++ 1.9 compiler, it is just a question of running wmake. Happy hacking!
Just a guess, but from the description it sounds like Windows 95 wants the Winsock 2 update (see Q182108.) This update was itself updated a few times, so pay attention to its version.
I tried building the source with OpenWatcom, but it’s failing with:
X:\Dev\box9x\boxv9x-0c8e36318ee3>wmake
Open Watcom Make Version 1.9
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wcc -q -wx -s -zu -zls -3 -zW -IW:\WATCOM\h\win -Iddk dibcall.c
W:\WATCOM\H\NT\winnt.h(6333): Error! E1185: Invalid register name ‘eax’ in #pragma
Did you not install 16-bit Windows support? It’s clearly including the 32-bit windows.h, but there should be a 16-bit one in W:\WATCOM\h\win.
Oh, that was the problem – I thought I installed 16-bit Windows support, but I only installed 16-bit compilers.
Anyway, I made the highest supported resolution 7680×4320 (8k), and Windows 95 works without problems at 8bpp: https://eternallybored.org/imgs/compstuff/win95_8k.png (there’s some screen corruption at 16bpp, and I didn’t try anything higher).
Hehe, very nice 🙂
On a tangent, you made me remember that at that time Microsoft was selling Microsoft SourceSafe as their CVS. I installed it, play it a little and never used it again, can’t remember much about SourceSafe.
Thank you Michal! I compiled my own version without the C1_SLOW_CARD flag so that disabled text shows up with the embossed effect.
Huh, is that documented somewhere? What else does the C1_SLOW_CARD flag do?
Maybe the flag shouldn’t be set because by the standards of mid-1990s graphics cards, the software-only rendering in a VM is pretty darn fast.
I don’t think there is any actual documentation, but Raymond Chen talks about it while discussing SM_SLOWMACHINE: https://devblogs.microsoft.com/oldnewthing/20070312-00/?p=27653
Relevant Quote: “The guidance in the device driver documentation was to mark a driver as slow if it did not perform graphics hardware acceleration, but of course no card manufacturer would admit that their card was slow! I suspect nobody ever set that bit.”
Well, the unaccelerated DDK sample minidriver does set the flag 🙂
The VGA driver sets C1_SLOW_CARD too, which actually means it’s more less guaranteed to be set in Safe Mode. Which may well have been intentional.
Thanks for pointing this out, it definitely counts as obscure.
Since this is about Win9x (DOS-based), it reminds me of DOS.
The old DJGPP build of Python is 2.4.2 (2008?), and one guy said the latest Mercurial to work there was 3.4.2:
* http://matejhorvat.si/en/dos/hg/index.htm
Just FYI, for completeness.
Thanks. I came across the DOS-based Mercurial before, haven’t tried it (since the Win32 build worked on Win9x), but I noted it and will probably try it out at some time in the future.
I can’t imagine almost after 15 years the drivers for Non-NT windows finally came out,for an completely open-source hyperviso ,the free riders are who making companies like Micro$oft success
Thanks for the great driver. It works on QEMU, too, with a few changes. I published them up on GitHub:
https://github.com/phkelley/boxv9x
The VGA virtualization has a problem – if you open a new DOS Prompt, the screen goes black until you hit ALT-ENTER twice (to switch to full-screen mode and then back again.) I think this is because the DOS VM calls into the VGA BIOS, which in QEMU is enlightened and knows about the DISPI interface on I/O ports 0x1ce and 0x1cf. So the VGA BIOS ends up switching the device out of hi-res mode whenever you start a new DOS Prompt! When using an enlightened VGA BIOS like this, a mini-VDD VxD is probably required to hook the I/O ports and virtualize them for the DOS VMs. I’m not sure if you’ve seen the same thing on VirtualBox or not.
No, that does not happen on VirtualBox. It has a different interface for the VGA BIOS to get out of a VBE mode, and that does not kick in when Windows virtualizes the VGA registers (because it uses a VGA register extension).
You’re almost certainly right that a VDD would be needed to get around that with QEMU.
But I’m glad to hear it mostly works!
Hi, Michal Necasek
Is there any chance to get the NT video miniport UHD (boxvnt) driver qemu compatible ? I want to use it for Windows XP VM with qemu.
Thanks for the great driver
Anup
Sure there’s a chance, but I won’t be doing the work.