How to Install and Configure Applications on FreeDOS

This walks through installing and properly configuring applications on FreeDOS — using the bundled EDIT text editor as the primary example, plus the general pattern for adding any additional package afterward.

Step 1: check what’s already installed

FreeDOS’s Base package set includes a text editor already — confirm it’s present before installing anything extra:

C:\>DIR C:\FREEDOS\BIN\EDIT.EXE

Step 2: launch and get familiar with EDIT

C:\>EDIT CONFIG.SYS

EDIT provides a full-screen, menu-driven text editing experience (accessible via Alt to open the menu bar) — considerably more approachable than line-oriented alternatives, and sufficient for editing configuration files like CONFIG.SYS and AUTOEXEC.BAT directly.

Step 3: install additional packages via FDIMPLES

For anything not included in your initial installation’s package selection, use FDIMPLES’ menu-driven interface:

C:\>FDIMPLES

Navigate the category list, select packages you want (space bar typically toggles selection), and confirm to install — this handles downloading (if networked) or installing from local media, and registering the package in FreeDOS’s package database.

Step 4: install a package directly via FDNPKG, if you know its name

C:\>FDNPKG install nasm

Useful when you know exactly what you want (in this example, the NASM assembler) without navigating FDIMPLES’ full category menu.

Step 5: confirm where the new package actually installed

C:\>FDNPKG list

Most FreeDOS packages install under C:\FREEDOS\BIN\ or a dedicated subdirectory — confirm the new executable’s location before assuming it’s reachable from your PATH.

Step 6: make sure your PATH actually includes it

C:\>PATH

If the new application’s directory isn’t already in your PATH, add it in AUTOEXEC.BAT so it’s available at every boot, not just for the current session:

SET PATH=%PATH%;C:\FREEDOS\BIN;C:\NASM

Step 7: for applications needing specific environment variables

Some applications (compilers and development tools especially) expect specific environment variables pointing to their own installation or data directories — check the application’s own documentation and add these to AUTOEXEC.BAT alongside the PATH update:

SET NASM_HOME=C:\NASM

Step 8: reboot and confirm the application launches from anywhere

C:\>CD \
C:\>NASM -v

Running the new command from a directory other than where it’s installed confirms your PATH update actually took effect, rather than the command only working because you happened to be in its own directory.

Step 9: for applications distributed outside FreeDOS’s package system

Not every useful DOS-era application is available as a FreeDOS package — for anything distributed as a standalone .zip or self-extracting archive, extract it to its own directory under C:\, and follow the same pattern: confirm the executable’s location, add it to PATH if you want it globally reachable, and set any environment variables its documentation specifies.

Why FDIMPLES/FDNPKG plus manual PATH management, together

FreeDOS’s package tools handle installing files to a sensible default location and registering them in the package database, but — unlike a modern package manager — they don’t automatically manage your shell’s PATH or environment variables for you. Understanding this two-part model (the package tool installs files; you wire them into your environment via AUTOEXEC.BAT) is what makes troubleshooting “installed but not found” issues straightforward rather than mysterious.

Where FreeDOS’s EDIT actually comes from, versus genuine MS-DOS EDIT

Genuine MS-DOS’s own EDIT.COM has a specific, slightly unusual history: introduced in MS-DOS 5.0, its first version was actually a thin stub that launched QBasic in a special editor-only mode, rather than being a fully standalone program — it wasn’t until the version bundled with Windows 95 that EDIT became a genuinely standalone application no longer depending on QBasic underneath. FreeDOS’s own EDIT is a completely independent, from-scratch reimplementation rather than a port or derivative of Microsoft’s code, built specifically to provide equivalent full-screen editing functionality and a familiar menu-driven interface without depending on any Microsoft-derived source at all.

Confirming FDNPKG has current package information before installing

Before either FDIMPLES or FDNPKG install for a package you haven’t installed recently, updating the local package list (FDNPKG update, if your configured repository is networked) ensures you’re seeing the current available versions rather than a possibly-stale local cache — particularly relevant if your FreeDOS installation is itself not brand new, since package availability and versions do change over time.

Uninstalling a package cleanly if it turns out you don’t need it

C:\>FDNPKG remove nasm

FDNPKG remove (or the equivalent deselection through FDIMPLES) removes both the package’s files and its registration in the package database — worth using instead of manually deleting files yourself, since manual deletion leaves the package database believing something is installed that no longer actually exists on disk, which can confuse later package operations that check for conflicts or dependencies. Note that this removes just the package name (fdnpkg remove nasm), not the archive filename you originally installed it from.

Related:

Sources: