FreeDOS 1.2 Arrives After Nearly Five Years
FreeDOS 1.2 shipped December 25, 2016 with the new FDI installer, FDIMPLES package selection, multiple USB and CD images, and a much broader software catalog.
FreeDOS 1.2 was released on December 25, 2016, four years and almost twelve months after FreeDOS 1.1. Its defining improvement was not a new DOS API or a radically different kernel. The project paired refreshed packages with the new FreeDOS Installer (FDI), multiple installation-media formats, and FDIMPLES, a menu-driven way to add or remove programs after setup.
The official announcement centered the installer
The FreeDOS Project’s release announcement calls 1.2’s installer “all-new” and directs users to FDIMPLES after installation. That emphasis corrected a concrete weakness in 1.1, whose own announcement documented broken CD detection, incomplete boot menus, and a distribution limited to the BASE set.
FDI was a customizable installation kit built from DOS batch files and V8Power Tools. It located package sets, collected installation choices, prepared the destination, and installed a selected profile. That is different from claiming that FreeDOS suddenly became universally automatic. Disk partitioning and formatting remain destructive operations, and the correct boot path still depends on firmware, removable media, controller support, and the target machine.
Installation media covered several boot environments
The official 1.2 README lists full and lite USB images, a bootable CD, an alternate Legacy CD, a boot-floppy-plus-CD path, and installation from a separate hard disk. Each exists because “PC compatible” covers machines and virtual environments with different BIOS and CD boot behavior.
The normal CD path targeted most virtual machines and 486-or-better computers. The alternate Legacy CD used a different boot approach for systems where the standard image was unsuitable. A boot floppy could start installation on machines with a CD-ROM drive but no working CD boot support. USB images provided another path for newer systems that could boot them.
The README also describes a special DOSBox method that installs FreeDOS binaries and FreeCOM into a mounted DOSBox drive but does not replace DOSBox’s own emulated DOS kernel with the FreeDOS kernel. Calling that a normal FreeDOS operating-system installation would be inaccurate; the primary document explicitly distinguishes it.
Hardware requirements belonged to the installer, not all of FreeDOS
FDI’s documented requirements included EGA-or-better graphics, 640 KiB of RAM, and an 80386-or-better processor. The same document explains the nuance: V8Power Tools and FDI themselves could run on an 8086, but other utilities required by that installation flow did not support processors below a 386.
That does not prove FreeDOS 1.2’s kernel or every command required a 386. It defines the supported path for the standard installer. Users of older hardware needed a different preparation method or suitable media and packages. Separating distribution-installer requirements from operating-system architecture prevents a common historical error about FreeDOS abandoning original PC-class processors.
FDIMPLES made the package selection revisable
The release announcement invites users to run FDIMPLES to install additional programs or remove unwanted ones. This matters because a FreeDOS distribution contains more software than a minimal DOS environment needs. Editors, compilers, networking programs, games, archivers, graphical shells, drivers, and Unix-like tools have very different disk and hardware costs.
FDIMPLES gave that catalog a navigable interface instead of making installation a one-time, all-or-nothing media decision. Packages remained ZIP-based units with metadata and defined directory layouts. The interface did not erase license differences or hardware prerequisites; it made the package set easier to inspect and change.
The package comparison shows a broader distribution
FreeDOS’s archived 1.2 comparison page records package versions across the 1.2-all, full, base, 1.1, and 1.0 sets. It shows 56 packages in the 1.2 BASE group and separate collections for archivers, boot tools, development, drivers, editors, games, networking, sound, Unix-like tools, utilities, and more.
The useful conclusion is not that every program was newer than its 1.1 counterpart. The table explicitly marks many items “same” and lists packages omitted from narrower media. FreeDOS 1.2’s improvement was a curated, much broader catalog delivered through selectable profiles, not an unsupported claim that every component had been rewritten.
Examples from the comparison include FreeCOM 0.84-pre2, kernel 2042, CTMouse 2.1b4, DEBUG 1.25, and a variety of compilers and network utilities. Version numbers should be attached to individual packages, not treated as one synchronized FreeDOS codebase.
Integrity files made the media auditable
The release archive includes MD5 and SHA digest files beside the ISO and ZIP images. Checksums let users detect an incomplete or altered download before writing it to removable media. They do not by themselves authenticate who published a malicious replacement if both file and checksum come from the same compromised location, but they are valuable for transfer integrity and mirror comparison.
The archive retained separate artifacts for the CD, Legacy CD, floppy support, full USB, and lite USB paths. That preservation is primary evidence for what the project actually shipped on December 25, rather than a reconstruction from later repository state.
What FreeDOS 1.2 did and did not change
FreeDOS 1.2 made a fresh installation friendlier, restored a broad software selection after 1.1’s BASE-only release, and offered media for varied systems. It did not change FreeDOS into a protected-mode multitasking operating system, remove the need for compatible drivers, or guarantee that every modern computer could boot DOS without legacy BIOS support.
The release remained a 16-bit DOS-compatible environment assembled from independently versioned packages. Its modernization was distribution engineering: a new installer, more coherent software selection, revisable package choices, better media coverage, and documented requirements. For a project whose purpose is compatibility, those changes can matter more than inventing a new interface that old software would not recognize.
Related:
Sources: