Preface.

For those who want to cut to the chase, you can skip this section, as it just highlights everything that leads up to this project.

I'm sure we've all been there - waiting for the brand new disk partition to format, riding through the usual motions of installing Windows 95, scurrying for the right driver/update disks, and losing countless hours that could've been spent playing Diablo. While the traditional method of installing old versions of Windows with a boot floppy and a setup CD will eventually get your computer in the state you want it in after manually installing everything, it's incredibly tedious if you find yourself reinstalling Windows regularly, needing to deploy many computers for a LAN party, or just having little free time to work with. While I personally have more time on my hands than I'd like to admit, I still didn't want to wait through so much of the installation and have to constantly attend one or more computers, so I needed another approach.

Windows NT Server has a nifty program called Network Client Administrator, which can be used to copy the barebones DOS network drivers to a DOS boot floppy and generate client-specific information for it. Each floppy disk would then be inserted into a respective client, boot from it, log in with an account that can read from the Clients share, and run through the installation procedure without the need for a CD-ROM. This works well, but floppy disk access is still very slow. With a few small utilities, I created boot images that prompt for a computer name before loading the network drivers, one for each operating system. With a bunch of PXE-capable network cards handy, booting from a floppy image over TFTP becomes much quicker since it is copied to RAM, though changes to the RAM floppy are not persistent across reboots.

The next point of concern is reducing user intervention while running the setup program. Windows 95 and later operating systems include a built-in mechanism to automate some or all portions of the installation by reading from an answer file, the default being MSBATCH.INF. This file can be typed by hand entirely, or a program on certain Windows 95 CDs called BATCH.EXE can be used to generate one. It's a very useful program, but its limitations require appending to the answer file manually, which in turn requires knowledge of the structure of INF files. By manually adding registry entries, file copying lists, and updates for certain system configuration files, I was able to conduct a near-fully automated installation of Windows 95 complete with updates and drivers for all the detected devices.

Still, the hard drive needs to be reformatted each time a clean installation is to be carried out. The /q switch can be used EXCEPT when you create a brand new partition in FDISK for MS-DOS. If you happen to be formatting a large hard drive, you're going to wait a very long time for it to finish. Third-party partitioning tools like Super Fdisk or GParted do away with the mandatory full format, but I wanted to have my hard drive repartitioned and prepared for an installation automatically.

With some inspiration from an old Linux Gazette article, Core Linux became involved in the setup process. Advanced built-in scripting capabilities opened up new possibilities like automatically determining which DOS network driver to use by reading dmesg, and reading a remote text file to automatically specify a configuration to use based on the network card's MAC address. It required a lot of work over the course of four days, but once I had that set up, I thought I couldn't do much better... but then, a few additional modifications such as copying ALL of the setup files to the hard disk rather than a minimal DOS network client allowed Windows 95 to install even faster with less user intervention. This could do wonders for anyone else who's felt bored from installing Windows on many computers, but the main problem is that it was purpose-built for me only, and is not that user-friendly. A total rewrite of the solution proves to be necessary if I am to release it.

Enter HIERMA!

HIERMA is a set of Linux shell scripts and files I've been working on for the past two weeks so far. Provided you supply your own install CD, extracted drivers, and updates, Hierma will simplify the automation of Windows 9x Setup by preparing the hard disk to boot into a DOS environment that automatically runs your setup program with a total or near-total lack of user intervention up until everything has been installed (see issues section). For novice users, I'm creating a series of dialogs that guide them through the procedure, asking for input wherever necessary.

Expert users can run Hierma in a non-interactive mode using an existing database section. I'm not sure exactly how it'll play out, but ideally I'd like it to be done in a variety of ways, like selecting the answer section to use after booting to the program, or having it initiate a certain installation hands-free based on a MAC address specified in the database.

Once I complete this project, I plan to distribute it as a bootable ISO based on Core Linux and as a standalone script set that can run on top of an existing Linux or Unix-like system. The standalone script will be useful if you have one or more secondary hard drives in a system so you can prepare all of them at once. The boot CD will require at least 64MB of RAM installed in your system, so you might need to run it on a different machine if your target system has less than that. Even so, memory modules for old systems are super cheap nowadays, and I would recommend installing 64MB of RAM in Pentium 1 systems, anyway. Both variants will come with a tiny FreeDOS boot image to be used in the installation procedure, but you can also supply your own MS-DOS floppy if desired.

The initial release of Hierma will support all three releases of Windows 95, both editions of Windows 98, and Windows ME.

What does it do? Why should I use it?

Simplifying the automation of installing Windows is one key feature of Hierma, but not the only one. When Windows 95 searches its INF or (if DriverPath=1 is set in MSBATCH.INF) setup path for driver INFs, it expects to find the corresponding driver files in whatever the SourcePath setting in the registry is, which is the setup directory itself. This can lead to problems if you have drivers sharing filenames, such as the 3dfx Voodoo series. You'd have to rename some of the files and update the INFs accordingly. Hierma takes care of all of that for you by renaming duplicate files with numeric extensions and updating the destination INFs, or, if the data in two conflicting files match exactly, the new file is skipped. Drivers can be sourced from any directory and/or medium, and Hierma searches for drivers in all subdirectories from there.

Another feature of Hierma is the ability to lay everything out for Windows to install updates, programs, and modifications. Since it's not always consistent as to which stages of Windows Setup that specific updates should be applied, I want to make this part as modular as possible. I've yet to create a working prototype for it, but I'm expecting everything to involve a menu or checklist of separate scripts that the user can run to configure a variety of settings like enabling user profiles, showing all files in Explorer with extensions, forcing a specific monitor refresh rate, and updating DST information. I'll also include many premade scripts in Hierma for loading RunOnce and post-Setup updates, including the USB supplement for Windows 95 OSR2 and later DirectX versions. (to reemphasize, non-free software packages like the aforementioned updates will NOT be included, just wanted to make that certain)

I expect to create an interactive disk partitioning dialog as well, which should allow the user to create FAT16, FAT16 LBA, or FAT32 partitions of whichever sizes they please, or create a single partition spanning an entire disk. Of course, partitioning will be completed in a matter of seconds thanks to a set of filesystem utilities available for Linux.

What about Windows 2000, or MS-DOS and Windows 3.1?

I do not plan to support DOS, Windows 3.1x, or Windows NT-based operating systems in the initial release, but I do have them in mind for later releases, along with dual-booting capabilities using SYSLINUX, or maybe GRUB or LILO if you prefer. DOS and NT4 aren't as capable of automatically detecting devices, so additional workarounds will need to be created. If I can find the right utilities to detect all sorts of PCI and ISA devices and their hardware configurations (both PnP and non-PnP), you might be able to get that Sound Blaster card working straight away in your new DOS gaming machine as if Windows 95 detected it.

If any of you are interested in this project, I'll report back with progress updates weekly. I'm looking forward to hearing what you think of this!