Windows 98 SE VM on x86_64 Linux host

Last modified: Fri Aug 2 20:12:46 EDT 2019

Support for W98SE virtual machines (VMs) in current hypervisors is surprisingly weak.

VirtualBox

VirtualBox ("vbox") has such complicated and invasive dependencies, including an out-of-tree kernel module, that attempting to get it working on Slackware looked hopeless. Instead I spun up Ubuntu 16.04 LTS (Xenial) in a spare partition and installed the binary package of VirtualBox 5.0.20 from Oracle's archive using apt-get.

Vbox supplies a template for Windows 98 VMs, albeit with the warning that only "limited testing has been performed." I made the following changes to the defaults:

Increased memory size to 384 MB.
Increased HDD size to 8 GB.
Enabled I/O APIC.
Disabled network.
Disabled USB. (N.B., serial ports were already disabled.)
Changed boot order (once the HDD was bootable).

The customized boot image that I had been using ever since it worked on Wildcat Point led to a lockup as soon as the CD driver was used. Replacing XMGR.SYS, UDVD2.SYS, and SHSUCDX.COM with the original 3 drivers HIMEM.SYS, OAKCDROM.SYS, and MSCDEX.EXE got rid of the lockup. I did not revert all the way back to the original boot image, which tries to load many other extraneous drivers.

Booted the install CD, allowed setup to fdisk and format to its preference.
On the second reboot it locked up with a black screen. I killed and restarted vbox, and it proceeded.
On the third reboot it gave a blue screen of death, but I hit a key and it continued.
Then it had a random failure, trouble copying some file. I clicked OK and it continued.
The desktop appeared and sound was working.
The CPU idle patch was not needed.
Installed IO.SYS from kb311561.
Installed VBEMP 9x Universal VESA/VBE Video Display Driver, restarted, and changed desktop to 800×600 32bpp.
Installed 269601usa8.exe = the WDM audio update from kb242937.
The resulting VM boots and shuts down cleanly. Hardware-assisted virtualization is allegedly "active." Performance is good.

The serious failures that occurred during installation show that vbox's emulation of vintage hardware has problems, but it is an order of magnitude better than QEMU, and the resulting VM was usable.

Hidden support for raw image files

First, create the raw image file and put a partition table in it.

Then, generate a vmdk file as follows: VBoxManage internalcommands createrawvmdk -filename W98SE.vmdk -rawdisk W98SE.img

The resulting vmdk file (a small text file with fields that note things like disk geometry, UUID, and the path to the raw image) can then be added as an existing virtual hard disk in vbox.

This function is not properly documented. The VBox manual does not indicate support for raw format disk image files. Even the createrawvmdk examples in the Advanced Storage Section don't mention that it works with raw image files. Thanks to Linux User #330250 for making me aware of a relevant answer on Stackoverflow.

QEMU/KVM

QEMU integrates with KVM to provide hardware-assisted virtualization and emulates hardware of the appropriate vintage for running W98SE. Unfortunately, support for W98SE in QEMU and KVM have not been maintained, assuming that they ever worked at all.

Tested qemu-2.6.0 with kernel 4.5.0.

Build:

./configure --prefix=/usr/local/qemu-2.6.0 --audio-drv-list=alsa,sdl --enable-seccomp

Run:

QEMU_SHARED_OPTS="-enable-kvm -m 384M -sandbox on -machine pc -cpu pentium2 -display gtk -vga std -no-hpet -no-acpi -soundhw sb16,pcspk -drive index=0,file=rawhdd.img,format=raw,media=disk,readonly=off"
export QEMU_AUDIO_DRV=alsa

# Must first fix permissions on /dev/kvm
qemu-system-i386 ${QEMU_SHARED_OPTS} -cdrom W98SE.iso -boot d

Despite KVM, installation ran much more slowly than it did with VirtualBox.

qemu-img create -f raw rawhdd.img 8G
Booted the install CD, allowed setup to fdisk and format to its preference. UDVD2 said "BAD controller at ..." but it wasn't a showstopper.
Every attempt to boot from the HDD locked up with a black screen. After restarting, the startup menu with safe mode or step-by-step confirmation would come up. Choosing step-by-step confirmation and then accepting all of the default responses (hitting Enter a lot) somehow enabled it to proceed.
At one point it blue screened and locked up. Restarted, kept trying, it proceeded.
After lots of fighting I made it to the desktop. Sound was working, but looping and breaking up with high CPU load.
The CPU idle patch was not needed.
Installed IO.SYS from kb311561.
Installed VBEMP 9x Universal VESA/VBE Video Display Driver, restarted, and changed desktop to 800×600 32bpp.
Installed 269601usa8.exe = the WDM audio update from kb242937.

Problems with resulting VM:

The display now enters a trashed state whenever I try to open a DOS box or run a batch file.
Windows no longer shuts down cleanly. Scandisk runs after every boot, followed by the black screen of death and having to restart in step-by-step mode.
Softsynths cause such a high CPU load that everything else in the VM freezes. Only one of them was able to function without the sound skipping and breaking up.
General flakiness, lockups, random boot failures.

Warnings printed by QEMU included:

main-loop: WARNING: I/O thread spun for 1000 iterations
sb16: warning: command 0xfa,0 is not truly understood yet
sb16: warning: command 0xf,1 is not truly understood yet
sb16: warning: command 0xe,2 is not truly understood yet
sb16: warning: command 0xf9,1 is not truly understood yet

Differences when KVM is not enabled:

QEMU prints an additional warning: TCG doesn't support requested feature: CPUID.01H:EDX.vme [bit 1].
Sooner or later it stubbornly locks up at the CD-ROM startup menu. To make progress, change the command-line option to -boot c.
More than once it locks up at the W98SE splash screen. Kill and restart QEMU.
When arriving at the desktop, it locks up every time unless and until the SB16 device is removed.
On the good side, every boot does not need to go step-by-step.

DOSBox-X

DOSBox-X (henceforth dbx) got to a Windows desktop without all the flailing, but the resulting VM was still unusable.

Tested git sources cloned on 2016-06-04.

Build:

# x86 dynamic cpu core cannot be enabled for x86_64.
./configure --prefix=/usr/local/dbx --with-sdl-prefix=/usr/local/SDL \
  CPPFLAGS="-I/usr/local/fluidsynth-1.1.6/include" \
  CFLAGS="-O2" CXXFLAGS="-O2" \
  LDFLAGS="-L/usr/local/fluidsynth-1.1.6/lib"

Run: dosbox-x -conf ~/tmp/dbx.conf

Here is dbx.conf. These settings were not necessarily optimal; I found out afterward that the best available documentation is the comments in the default config file that you get by typing config -all -wcp /tmp/default.conf at the Z: prompt.

The hotkey to release the mouse grab is Ctrl-F10.

dd if=/dev/zero of=hdd.img bs=1G count=8 8589934592 bytes (8.6 GB) copied
It refused to boot from the CD image, so I did fdisk and format /s c: from a boot floppy image.
imgmount 0 "W98SE-cleaner.img" -t floppy -fs none imgmount 2 "hdd.img" -t hdd -fs none -size 512,63,16,16644 -ide 1m boot -l a
Mounted the HDD image and copied the contents of a W98SE install CD to a directory, WINCD.
mount -t vfat -o loop,uid=1000,gid=100,shortname=winnt,offset=32256 hdd.img /mnt cp -a W98SE-current /mnt/WINCD umount /mnt
Changed dbx.conf to remove the boot floppy and boot C instead.
Ran dbx, cd into WINCD, and ran setup.exe. It took a long time and dbx logged lots of errors to console.
At the first reboot dbx crashed with this:
E_Exit: DOS:Attempt to use DOS_GetMemory() when private area was unmapped by BOOT
Restarted dbx and continued.
Made it to the desktop. Sound was working, and a driver for the 3dfx Voodoo was already installed. Turned up the volume and changed the video settings to 800×600 32bpp.
Installed CPU idle driver AMNHLT (amnhltm.zip).
Installed IO.SYS from kb311561.
Installed 269601usa8.exe = the WDM audio update from kb242937.
Attempted to install two softsynths. Each one caused the VM to become unbootable.

Bugs, quirks, and limitations in the tested snapshot of dbx:

OpenGL is broken. No scaling, no fullscreen. Blah.
With machine=svga_s3 it actually emulates a 3dfx Voodoo.
Dynamic core is not available in x86_64, and the emulation is very slow.
With cycles=max, the window title bar shows cycles=3000, but it's actually max.
There's no hint telling how to release the mouse grab (Ctrl-F10).

KB
Home