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.