# Windows 9x QuickInstall for fast, driver-rich installation

> Windows 9x QuickInstall replaces the standard Windows 9x setup environment with a Linux-based installer and integrated driver library. It suits retro-computing users who need a repeatable way to deploy prepared Windows 98 or ME images across old and modern hardware.

**oerg866/win98-quickinstall** — A framework + installer to (very) quickly install Windows 98 on anything from a 486 up to a modern system

- Repository: https://github.com/oerg866/win98-quickinstall
- Stars: 1,773 · Forks: 60
- Language: C
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/oerg866-win98-quickinstall

## Why QuickInstall targets a different Windows 9x workflow

Windows 9x QuickInstall addresses installation speed and hardware coverage, but it is not merely another copy of the Windows 98 installer. Its intended users are people restoring a large collection of acquired hardware, building machines from period components, or installing Windows 98 or ME on systems that the original setup process handles poorly. The repository description explicitly spans 486-class computers through modern systems, including machines with UEFI, NVMe storage, USB 2.0, and AHCI.

The project starts from an already configured and working Windows installation rather than assembling the operating system from a stock distribution during each deployment. Patches, drivers, and software already present in that installation remain part of the image. QuickInstall removes the stored hardware-detection information after preparation, then allows the Windows 98 Setup hardware detection phase to run again on the destination machine. At that point, the installer can draw from its bundled driver library instead of relying only on the hardware profile saved in the source system.

This design targets repeatable image deployment, not first-time operating system customization. Someone creating a new QuickInstall image must still prepare a working Windows 9x installation and decide which software, patches, and drivers belong in it. The result is less convenient for a novice than a conventional installer, but it gives experienced users control over one reusable installation image. The README also presents pre-built reference images as a separate option for users who do not want to perform all image preparation themselves.

## MercyPak changes the Windows 9x deployment mechanism

The central technical choice is MercyPak, a custom flat binary format described by the README as being read once and in sequence. During deployment, the Linux-based installation environment writes a prepared installation image to a selected target directory. Because the payload is laid out for sequential reading, it avoids the repeated seeking associated with installing many smaller files from CD-ROM media.

This is more than a filesystem wrapper around a standard Windows installation. The prepared installation is processed so that the usual Setup phase can be replaced or bypassed by the QuickInstall environment, while hardware detection is rerun against the destination. The boot medium therefore has two related jobs. First, it must start the custom kernel and locate the QuickInstall data. Second, it must install the Windows files and preserve a path for detecting hardware against the bundled drivers.

The README says the installation environment finds its files after the kernel starts, regardless of whether the machine boots from floppy, optical media, USB, SD, or CF storage. That separation also allows a system without USB boot support to start from the supplied floppy environment and obtain the installation data from USB. The approach is aimed at reducing media seeks and installation time, but it also creates an image format that is specific to QuickInstall. A user cannot assume that a prepared image is interchangeable with a normal ISO or that it can be modified like an ordinary Windows installation source.

## Boot media selection for QuickInstall systems

QuickInstall supports several starting paths, which is important for a project intended to span both period machines and modern computers. The README names native floppy boot through `floppy.img`, CD or DVD-ROM boot, DOS-based booting, and USB flash drives, SD cards, or CF cards. It also explicitly identifies UEFI systems as a supported USB storage scenario.

The available path depends on the machine rather than on a single recommended medium. An older system with a floppy drive can use the native floppy image. A CD or DVD-ROM system can boot the optical environment directly. A computer that cannot boot USB can start from the boot floppy and still access QuickInstall files located on USB. This is a practical distinction for retro hardware, where USB boot support and firmware behavior can vary considerably.

The repository includes components such as `dosflop`, `syslinux`, `busybox`, `linux`, `dosfstools`, and `util-linux`, plus a `tiny-floppy-bootloader`. Based on this repository layout, QuickInstall is a complete embedded installation environment rather than a small installer application that expects an existing Linux distribution. It also includes `installer`, `init.sh`, and driver-library submodules, indicating that boot startup, image deployment, and bundled Windows drivers are separate parts of the system.

The README does not document rollback, unattended deployment, or recovery after a partial image write. Those omissions matter because the partition tool can wipe a disk partition table. QuickInstall is therefore better suited to an informed installation operator than to an unattended deployment pipeline with strict data-retention requirements.

## Preparing a QuickInstall image before the first installation

The README does not give a direct command for downloading and installing QuickInstall, nor does it present a complete first-run command that can be copied from its installation instructions. It directs users to `BUILDING.md`, `IMAGE_CREATION.md`, and the framework-building material for that process. The repository contains `build.sh`, build scripts, Linux components, SysPrep resources, and driver libraries, but the README does not document the arguments or prerequisites for that script. Supplying a fabricated `git clone` command, build invocation, or release URL would go beyond the project's published instructions.

The first real deployment therefore begins only after the operator has obtained or built boot media and prepared a QuickInstall image. The bootable environment provides a main menu, a hard-disk partitioning tool, and an installation entry. The partitioning step can wipe a disk partition table, so the operator must confirm the intended target before continuing. The installation environment then writes the image to the chosen target directory.

A source installation supplies the base content. The creator determines which patches, applications, and drivers are already installed, after which the image is stripped of its hardware-detection information. At boot time, detection runs again and accesses the QuickInstall driver library. The driver collections are split into `win98-driver-lib-base` and `win98-driver-lib-extra`, which gives image builders a visible choice between core and additional driver sets.

This tutorial boundary is material. QuickInstall does not eliminate the hardest part of creating a dependable image. It accelerates deployment of an image whose contents have already been selected and prepared.

## QuickInstall and nLite solve the same broad problem differently

The README explicitly compares Windows 9x QuickInstall with nLite, but it emphasizes that the implementation is substantially different. The README says the two approaches are not dissimilar in purpose, but their methods differ substantially. QuickInstall goes further by deriving images from an already configured installation, removing its hardware information, and deploying the result through a custom Linux environment and MercyPak payload.

That approach has two practical consequences. First, the image can retain software, patches, and drivers already present in a known working installation instead of limiting the base image to whatever stock installation process supplies. Second, the destination retains a hardware-detection phase, allowing QuickInstall to select drivers appropriate to the machine being installed. The README associates this design with deployment across a broad range of hardware classes.

The comparison also exposes a trade-off. QuickInstall requires more effort to build an ISO than nLite, according to the project, although it offers greater customization. It is consequently suited to operators who repeatedly build and deploy images rather than someone who only wants a lightly modified stock installer. The repository does not claim that QuickInstall preserves every original Microsoft setup step or reproduces the normal installation path exactly. Its image format and Linux installer make it a separate system with its own compatibility questions.

## Reported installation speed, support scope, and legal boundary

The README reports elapsed installation times of 15 seconds in VirtualBox on a modern machine, 60 seconds on a Pentium III 866MHz with a DVD-ROM and ATA133 disk, and 5 minutes on a 486 DX4-100. These are project-reported examples, not independent measurements, and the README does not define every preparation step covered by those figures. Still, they show that the intended speed claim varies with the storage path and processor class rather than presenting one fixed duration.

The project claims support for old and new hardware, including 486-class systems, modern Ryzen and Core Ultra systems, UEFI machines, NVMe SSDs, native USB 2.0, and AHCI. That breadth is a feature of the prepared driver library and custom environment, but it should not be read as guaranteed support for every device. The troubleshooting instructions explicitly direct users to disable skipping legacy non-PnP detection and, where possible, test with the driver library turned off. This confirms that detection can vary by hardware path.

There is also a clear geographic restriction in the README. It warns that QuickInstall is not labeled, approved, or intended for use in California, cites California AB1043, and says not to use the project while located in or resident there. Separately, the repository does not display a license identifier. Neither point is legal advice. Users must confirm the license of the framework and every patch, driver, application, and Windows image they distribute. The README also states that Windows is a Microsoft trademark and that Microsoft does not endorse QuickInstall.

Maintenance can be assessed from the repository's release history. The latest listed release is `v1.1.0` on 2026-09-19, preceded by `v1.0.1` on 2026-03-09 and `v1.0.0` on 2026-02-15. The repository is not archived, and the last push was on 2026-09-19. Its primary language is C, while the embedded environment also contains Linux, DOS, shell, and build components. Upgrade work may therefore affect the C installer framework and several bundled subsystems, but the README does not publish an upgrade procedure or compatibility policy.

## Conclusion

Windows 9x QuickInstall is a practical choice for retro-computing enthusiasts who repeatedly prepare or deploy Windows 98 and ME systems and can work with its image-building workflow. It is a poor fit for users who need a simple Microsoft-supported installation, an unknown licensed distribution, or a turnkey installer without image preparation. The first checks should be the exact target hardware list, the contents and provenance of the chosen Windows image, and the licensing status of that image. The repository does not identify the project license, so redistribution and modification rights cannot be inferred from its GitHub metadata.

## FAQ

### What is Windows 9x QuickInstall used for?

It deploys prepared Windows 98 or ME installation images with integrated patches and drivers. The project targets machines ranging from 486-class systems to modern hardware.

### Does Windows 9x QuickInstall support USB and UEFI systems?

The README identifies USB flash drives, SD cards, CF cards, and UEFI systems as supported boot or installation scenarios. It also says a boot floppy can reach USB installation files on a computer that cannot boot USB directly.

### Does Windows 9x QuickInstall include an open source license?

The repository does not identify a license. Its licensing implications therefore cannot be determined from the GitHub metadata, and the licensing of bundled Windows content must also be considered separately.

## Sources

- [Issues](https://github.com/oerg866/win98-quickinstall/issues)
- [oerg866/win98-quickinstall on GitHub](https://github.com/oerg866/win98-quickinstall)
- [README](https://github.com/oerg866/win98-quickinstall/blob/master/README.md)
- [Releases](https://github.com/oerg866/win98-quickinstall/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oerg866-win98-quickinstall