I'm not sure if this is the right part of the forum to post about this, but I thought that if I share some information about the projects I am working on and have worked on in the past but never finished, I might get some feedback that encourages me to actually finish one of them 😀

Automated OS and application install tool for older PC software (DOS through Windows Me)

The goal is to have something that is a bit like virt-install, Vagrant or the Windows Embedded Image Builder.

What I have so far is a tool which can install combinations of DOS, Windows 3.1x, Windows 9x, Sound Blaster 16 and Cirrus Logic 5446 drivers (since they're useful in both Bochs and Qemu), Microsoft Office 4.3 in Windows 3.x, only requiring interaction in a few places I haven't gotten around to automating yet. This includes starting a 9x install from either DOS or Windows 3.1x.

The software that can be installed is defined using a directory structure a bit like the configuration for Ansible - directories with YAML files including Jinja templates plus other files. It's highly modular, so that it's easy to choose whether or not to include individual parts - it's not only possible to specify which OS, software and drivers to install, but to disable particular .inf file patches for example.

For example here is a package.yml file for a package that accepts the reboot prompt in Windows 95 Setup:

1inside: win95
2
3requires:
4  - install-temp-autohotkey
5
6patches:
7  bsetup.inf: |
8    {{ patch.outer("inf") }}
9
10    [Install]
11    AddReg=AddReg.{{ name }}
12
13    [AddReg.{{ name }}]
14    ; ... lengthy comment stripped out ...
15    HKLM,Software\Microsoft\Windows\CurrentVersion\RunOnce\Setup,"Automatically close dialog",,"%13%\start.exe {{ autohotkey }} {{ staging_path }}\{{ name }}.ahk"

In a sub-directory next to that script is the AutoHotkey script it runs.

Packages that install proprietary software don't include the files to be installed alongside them, but instead indicate what files the user must provide in their configuration:

1requires_sources:
2  - setup.exe
3  - "*"

This means that the user must point at a directory that contains a setup.exe file, but the entire tree will be copied rather than just setup.exe.

The user's configuration of package sources and parameters looks like this:

1win98seupg:
2  inherit: win98
3  source:
4    - /path/to/my98.iso
5    - win98/
6  params:
7    ProductKey: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
8
9install-temp-fdapm:
10  source:
11    - /path/to/FD13-LiveCD.zip
12    - FD13LIVE.iso
13    - packages/base/fdapm.zip
14    - BIN/

Here I'm defining win98seupg as a version of win98 - since I have a few different 98/98 SE versions in my configuration - and for install-temp-fdapm I'm just providing sources without defining it as a separate version because I have no interest in making different versions of a tool used only at install time. The last example means that the package files can be found in the BIN directory inside the packages/base/fdapm.zip file inside the .iso file inside another .zip file - if you have some source distribution files from the original distributor, and they're in a format this tool can handle, they don't need to be extracted, although currently it seems that for performance reasons it might be useful to extract them in some cases.

I've obviously used the automated installation methods provided by various versions of Windows, e.g. bsetup.inf. For the cases where various installers don't have unattended installation support, and for cases where Windows doesn't support full automation, I've used these tools:

- DOS: SCANCODE from Bret Johnson, who is probably better known as the guy who made the fancy DOS USB drivers
- Windows 3.x: A modified version of XLISP-PLUS, which is a whole other project that has spawned a few other projects.
- Windows 9x: AutoHotkey, but I couldn't find a version that worked on Windows 95 RTM without anything else installed and hence could be used inside Windows 95 RTM Setup, so I have a slightly modified version which I hope to release at some point.

Right now I can run something like tool-name-here --output-file hda.img --image-size 500M win311 win95upg cirrus-5446-win95-install and about 5 minutes later I'm sitting at a Windows 9x desktop in Bochs with working sound and super VGA, and can drop back into Windows 3.x with working sound and super VGA. I have to hack my code to use Qemu instead, obviously some way to select that would be nice.

I'd also like a way to generate a tree with all the installation files instead of putting them into a disk image so I can then run that on some other machine, ideally one day over the network after network booting.

I imagine a GUI like Windows Embedded Image Builder for selecting what to install but I'd better not think too far ahead!

I think the benefit of the scheme I'm using is that you can look at a package which does a single thing and see what changes are being made to bsetup.inf for example to accomplish that. Maybe even if everyone hates the tool itself they will find some of the package contents useful documentation about how to achieve things, since I often find forum posts online that just say "here is my bsetup.inf which works for me" and I don't know which parts are the important ones.

One of my goals is to use this as part of an automated test tool for software like Bochs and Qemu in the hope that if I catch bugs early it'll be easier to convince the authors to fix them, since I don't think they care too much about these old OSes, and it will hopefully be less work for them to fix bugs with them if they're reported quickly.

That was a lot of typing, I'll share a lot more soon.