How to Test Windows 3.1 on FreeDOS Without Risking a Working Installation

Windows 3.1 is not freeware and is not included with FreeDOS. If you have lawful installation media and a valid license, FreeDOS can be used as the DOS layer for compatibility experiments. Support depends on the FreeDOS kernel build, Windows mode, memory manager, and drivers; test on a cloned disk image, not the only working retro machine.

Build an isolated baseline

Create a new virtual disk or full sector image of the existing FreeDOS disk. Hash it and keep an untouched copy. In a VM, choose conservative hardware: IDE disk, VGA-compatible display, PS/2 mouse, Sound Blaster-compatible audio only if needed, and a NIC with documented DOS/Windows drivers.

Install FreeDOS and confirm clean boot, filesystem check, conventional/XMS memory, keyboard, and mouse before adding Windows. Record:

VER
MEM /C /P

FreeDOS Kernel builds have changed Windows 3.1 compatibility over time. The FreeDOS Project’s 2021 demonstration described Enhanced-mode work behind a compile-time WIN31SUPPORT option, and later kernel releases continued compatibility changes. Do not assume every distribution kernel or older 1.x installation has identical support; inspect SYS CONFIG and the release notes for the exact kernel.

Preserve a simple boot configuration

Windows Standard and 386 Enhanced modes interact differently with CPU mode and memory management. Start with the least complex FreeDOS configuration supported by the intended mode. Avoid stacking JEMM386, another DPMI/VCPI host, disk caches, network TSRs, and resident utilities before the base install works.

Create boot-menu profiles:

WINTEST: minimal XMS and mouse, no unrelated TSRs
NORMAL:  ordinary FreeDOS setup
CLEAN:   minimal recovery shell

Save FDCONFIG.SYS, FDAUTO.BAT, kernel, and command shell hashes. A bootable recovery image must be able to restore them without starting Windows.

Install only from original files into a new directory

Run Windows Setup from write-protected or copied lawful media and install into a dedicated directory on the test image. Do not point Setup at an irreplaceable historical installation. Select generic VGA and a basic mouse first; add accelerated video, sound, or network drivers one at a time after a successful reboot.

Windows Setup can modify startup files. Diff them against the baseline and understand every added driver or PATH change. Preserve SYSTEM.INI, WIN.INI, and the Windows directory after each stable milestone.

Test Standard mode before Enhanced mode

Standard mode exercises a smaller compatibility surface. If it fails, diagnose kernel, filesystem, memory, or basic Windows files before trying Enhanced mode. For Enhanced mode, use a FreeDOS kernel build whose documentation explicitly supports the required interfaces and a memory configuration known to work with it.

Do not “fix” a protection error by loading several extenders at once. Capture the exact message, Windows mode, kernel build, CPU/VM type, memory-manager versions, and startup files. A failure after the logo can be a VxD or display driver; a failure before it can be DOS/kernel/memory setup.

Treat drivers as untrusted kernel-era code

Windows 3.1 display, disk, network, and sound drivers execute with broad privilege and assume specific hardware. Use only trusted archived media, scan files on a modern system, record hashes, and keep networking disconnected until the system is patched/configured as far as historically possible.

Windows 3.1 and its browser/network software are obsolete and unsafe for the public Internet. Use a host-only network, packet capture, read-only file exchange, or no network. Do not expose SMB shares or credentials from a modern environment.

Define acceptance and rollback

Test cold boot into FreeDOS, Windows start/exit, Program Manager, file create/read, clock, keyboard, mouse, display mode, audio only if installed, and a second reboot. Then copy the VM/disk image and test restore. Verify that the normal FreeDOS boot profile still works without Windows.

Keep a matrix of kernel build, mode, memory manager, driver versions, emulator/hardware, result, and crash text. Compatibility is proven only for that matrix. The experiment succeeds when it is reproducible and disposable—not when one fragile configuration reaches the desktop once.

Related:

Sources: