So since I was looking at the Doom stuff, I thought I’d try to track down the WinG version of Doom, and luckily someone pack ratted away two versions! Needless to say the older one didn’t work for me, but the last one, the April 13th, 1995 build, worked just great!
WinDoom on Windows 7 x64
Even on Windows 7 x86_64, sp1!
So how much of a chore was this to run back in 1995, before Windows 95?
Well to start WinDoom requires a display capable of at least 256 colors. I thought I’d use Qemu for this, but this proved to be… exceptionally difficult to locate a satisfactory display driver. I know lots of people point to the SVGA.EXE update from Microsoft, that uses VESA extensions to drive the video. Oh sure it sounds great but this is what I got:
And.. corruption.
Ok, so you say, there is this great patch to enable better VESA support right?
Wrong.
Yeah. I also hunted down various cirrus drivers for the specifically emulated chip (I checked the source) and they were all consistently defective. So I tried using a lower chip driver from HP and amazingly the 640x480x16MM colors works! (well, works ‘enough’).
Installing the right driver.
It’s the GD5430 v1.25f, 640x480x16.8M
The next thing is that Doom in both MS-DOS and Windows are full 32bit executables. On the MS-DOS side, it relies on the DOS4G/W extender. For Windows, it relies on the then new Win32 standard, and Windoom was written to conform to the Win32s standard, meaning with an addon it can run on Windows 3.1, Windows 95, And Windows NT. I just fished around the internet and scored a copy of Win32s 1.25. I just remember this being a somewhat stable version.
Installing Win32s
Win32s installs pretty smooth, (as long as you remember the share.exe). Now we just need the WinG runtime to be installed. WinG was Microsoft’s first real attempt at high speed gaming video under Windows. From what I understand it kind of went down because it was ‘too difficult’, and buying DirectX seemed to be a better fit.
Setting the midi mapper.
Another thing I’ve found is that if you change the midi mapper from the default “Ad Lib” to “Ad Lib general”, you can at least get the midi working in Doom.
Once WinG is installed, then it’ll want to do some blit tests…
WinG calibrating.
And after that, we can even bump it up to glorious 640×400, something the initial MS-DOS version couldn’t do easily as VESA wasn’t a big standard with INSTALLED cards at the time, and it’d require lots of work from the iD team, where the move to Windows pushed all the peripheral development to the Vendors to work around Microsoft. Even to this day, it’s still a big deal with video and audio.
One thing that is cool about Qemu is that at compile time, you can put in adlib & soundblaster cards to give the ‘full’ Windows 3.1 multimedia experience. There is also GUS (Gravis Ultra Sound) support
in Qemu, but I’ve never played with it..
With all of that out of the way, WinDoom will launch.
WING dispdib.dll missing error that turned out to be Video for Windows.
Then it’ll throw an error, because Windows 3.1 doesn’t have the same video backend as Windows NT 3.5 (and higher), hit ok and then …
And it works! WinGDoom running on Windows 3.1 on Qemu!
Sadly on Windows 3.1 the sound effects do not seem to work, but overall it’s a GREAT little port, mostly because as it comes up on 16 years old, it still works, and with sound. I wish other OS’s could give this kind of support for legacy applications, even ones that had such a brief window of support.
Anyone crazy enough to even think of playing along can download the blob of software I used to get this going here (Updated on archive.org here: Windows-3.1-WING-doom)
I should also add if you want sound effects to work on WinDOOM you really should install the Video for Windows Runtime, and it’ll work… poorly on Qemu/SoundBlaster 16, but it does work!
Seems to work fine when running Windows 3.1 in DosBox (including music, but not SFX, though that's probably because there's something wrong with the SB drivers I used).
http://eternallybored.org/imgs/compstuff/windoomdosbox.png
Hmm I found a lemmings demo that uses WinG & Win32s, and I get the sounds but no midi.. And again it runs fine on my windows 7 x86_64 machine with both midi and wav…
I can only suspect that doom is in fact using direct sound or the audio in a fashion that Win32s simply cannot do.
I should check my basement if I still have the Windows Wonder CDs – I remember installing an X-Files screensaver that used WinG from there.
BTW, can you upload the Lemmings demo somewhere?
I forget where I found this but here you go:
http://vpsland.superglobalmegacorp.com/install/Windows3.1/demos/Lemmings.7z
I even added a quick post & download for Lemmings if this one doesn't appear right….
I got sound effects working on Windows 3.1 once I loaded in the Video for Windows runtime…
hi here 🙂 “WIn G” is used by PC version of COMIX ZONE 🙂 when you run it under Windows 3.1/3.11
Sure enough it is! I never knew there was a native port to the PC..
$ file *
Comix.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
Comix.ini: ASCII text, with CRLF line terminators
Comix_de.hlp: MS Windows 3.x help file
Comix_es.GID: MS Windows 3.x help file
Comix_es.hlp: MS Windows 3.x help file
Comix_fr.hlp: MS Windows 3.x help file
Comix_uk.gid: MS Windows 3.x help file
Comix_uk.hlp: MS Windows 3.x help file
Loader.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
Seqs.95: data
Sprites.bin: ACB archive data
Wail32.dll: PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit
Wing32.dll: PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit
Wail32 seems to be this AIL, which looks like it eventually became the Miles Sound System.
I uploudet a video using DOSBOX https://www.youtube.com/watch?v=lI0-WPXQjwE&feature=youtu.be 🙂
Hi again I found one more application that requires WinG
VGB 1.0 and probably below (read the lowest row in this version history)
http://fms.komkon.org/VGB/VGB.html
I found the screenshots from version VGB 0.7 in the PDF document with MSX and may be NES emulators again running from win 3.1x
but I can not find from where to download those early version
and so forgot to save this PDF and now can’t show it to you 🙁 I am continue to searching it …
I have spent a few days on a regular Indiana Jones quest of the Internet looking for this fabled HP GD5430 v1.25f Windows 3.1 driver, trying one Cirrus driver after another. The link to HP’s support site has gone dead, and their current driver support page has a search engine that requires an actual HP product number to look for anything. (I’m guessing they probably don’t have old Windows 3.1 Cirrus drivers anyway.)
Do you think you could post or link to the actual driver you’re using? After having tried many of them, I’m quite sure at this point that you’ve got something pretty unique and useful.
I’m guessing This is it?. You’ll get a 404, but read the 404 for the username password as they are auto generated.
Going through archive.org I see that this is the old page before the HP separation (ak the last & only time it was archived)
Type: Driver – Display / Monitor
Version: 1.25 A(5 Mar 1997)
Operating System(s): Microsoft Windows 3.1
Microsoft Windows for Workgroups 3.11
File name: sp2904.exe (2.0 MB)
Hope that helps
Thanks for all the help, but I’m getting “Error loading cirrus.drv” when Windows starts with this one. Also, I’ve noticed that not only with this driver, but also with a lot of the other Cirrus drivers I looked at while searching, there are no monitor frequencies supplied for any model of monitor (all frequency pulldowns are blank). It seems like some of the versions have that and some don’t, and the ones that don’t have any refresh options to choose from won’t even start Windows when the guest reboots. (That’s what I’m seeing with this one.) The ones that do supply a list of monitor frequencies for the pulldown menus usually will let Windows start, but the display is corrupted. For what it’s worth, I’m running QEMU 2.10.1 on Linux.
It’s ok if you don’t have any more ideas, because at this point, neither do I.
It’s probably the video settings… the older qemu got, the less it cared about preserving anything regarding older system comparability.
Granted I’m using Windows, but this ought to run on Wine I’d imagine.
This is version of Qemu 0.90 that I’ve been messing with. Mostly to tell you as you run it what it’s doing. It’s all GCC 3.45 built so it ought to be old enough to be stable. Qemu 0.90 was the last real great version before the GCC people messed up Qemu.
It’s ok, I already have Windows 3.1 SVGA working in DOSemu using Microsoft’s patched 256-color driver, but because I’m greedy and I want it all, I wanted to see if I could have it available and fully working in current QEMU as well, since each of these virtualization options has its own problems and advantages. (Certainly DOSemu is quite hit and miss.) It looks like, short of going back to an earlier QEMU, there’s probably no Windows 3.1 SVGA for me. Oh well…
The reason I’m doing all this old platform emulation is because I never want to give up my old MIDI/studio software. I more or less collect audio/MIDI tools on DOS, Windows 3.1, WIN32, MacOS, Commodore 64/128, Amiga, Atari, and I’m on Linux natively, and I try to have all the tools (toys?) available, in emulation if possible, but also actual old hardware is an option as well with its own problems and advantages. Basically, I’ve gone off the deep end with this. If it was only about the music, it would be crazy, but I like the production process enough that for me it’s also become about how the sausage is made.
Anyway, it amazes me that QEMU made this Cirrus emulation with the specific intention of being as compatible as possible, and it’s actually evolved into the finickiest video chipset real or virtual that I think I’ve ever seen anywhere. In WIN16, nothing will satisfy it. How compatible is that?
It’s always been anything but really compatible. I’ve found that setting the chip to a lower version, and using an actual ROM helped a LOT when it came to emulation but when others have found issues with the emulation patches have been rejected. Just as when the IDE emulaiton drifted out of working with things like netware and nextstep there was zero interest in trying to address them.
Qemu is just being used as the emulated hardware base for KVM to run Linux… It’s basically it’s entire reason for existing at this point.
Newer doesn’t meat better, the older versions were in many ways not only more compatible, but significantly faster. You just need GCC version 3 to build them.
Just thought I’d follow up about Windows 3.1 SVGA in QEMU:
Instead of using ‘-vga cirrus’, I tried for ‘-vga std’, and used the patched version of the Microsoft 256-color SVGA driver, just as I had done previously to get 1024×768/8bit in DOSEMU. It worked! The thing that disturbs me though is, I’m certain I did not neglect to try this before. In fact, the original post mentions doing this, so if I’d forgotten, this post would have reminded me to try it. And I’m sure I actually did, and it failed, just like it did for the OP author. I’m sure of it. So now I went back and tried it again, and now it worked.
It’s pretty slow — you can actually watch the screen draw lines and paint windows, just like with QEMU’s vanilla VGA, so it’s probably not going to be fast enough for many games. But without the driver, you’ve got 640×480 in 16 colors, and with it, a decent 1024×768 in 256, so it’s an improvement if only to have a big enough desktop that File Manager is comfortably usable.
My theory is that there are many strains and variations of the original Japheth SVGA patch floating around, and I’ve downloaded a lot of them. Maybe I tried a different one before? Anyway, use the SVGA driver here:
https://www.resourcemate.com/other/svga.exe
And the patch here:
https://download.wcnews.com/files/other/wcpc/svgaptch.zip
Run QEMU (even a modern version) with ‘-vga std’, which is now the default, so on a new version you can leave -vga unspecified. Patch SVGA256.DRV, install, and behold Windows 3.1 at 1024×768…still drawing pixels really slow, but at this point, I’ll take it.
I think it comes down the to the version of Qemu. I’ve been messing with the source, trying to add some other port mapped devices, I’d like to eventually take some other emulators video emulation and incorporate those… baby steps first.
I went chasing down this driver myself yesterday, then found this blog post in my old notes after a few hours of fruitless downloading/installing. It’s still working fine in modern qemu versions except for some severe font glitches right after startup. This resolves itself after a few redraws, though.
You must not use the mode switching utility that gets started automatically after installation. This it what leads to “Error loading cirrus.drv”. Just cancel it and select the desired resolution from winsetup afterwards. I guess not every possible selection works, but I can attest to this working: GD5434 v1.25f, 1280x1024x64K Smlfnt