FDNPKG16 on FreeDOS: Network Package Management on 8086-Class Systems

FDNPKG16 is a network-capable package manager for FreeDOS systems with 16-bit x86 processors. It is related to, but not interchangeable with, the original FDNPKG command covered by older FreeDOS guides. This walkthrough pins its examples to FDNPKG16 0.99.8254f, released in September 2026; it does not claim that this is the newest build. The October 2026 T2610 test-build announcement records the 0.99.8254f release in its change list, and the separate build report lists FDNPKG16 among the test-build packages without encoding a package version. On October 3, the maintainer posted 0.99.8260 RC1 for testing and said it would enter repositories once ready. Recheck the manual and sample configuration for the build you actually install, and validate this pinned workflow on a disposable image before using it on a system that matters.

Choose the 16-bit program deliberately

The project manual describes FDNPKG16 as supporting 8086/8088, 186, and 286-class processors. It is a maintained 16-bit-oriented branch based on FDNPKG, not simply a renamed copy: the manual says the original FDNPKG required an 80386, and FDNPKG16 removed less commonly used features such as LZMA while adding changes for older machines. Do not infer that every package is suitable for an 8086 merely because the package manager runs there; a package may itself require a newer CPU, more memory, or another runtime.

There are two similar names worth keeping separate. FDNPKG16 is the network-oriented tool discussed here. Its accompanying FDINST16 is described as a lightweight, low-memory utility for local packages only. If the target has too little memory for the network manager or cannot bring up networking, transfer and inspect a local package using the documented local-install workflow rather than assuming FDNPKG16 will silently switch into a low-memory mode.

Measure resources before bringing up networking

The 0.99.8254f manual specifies 480 KiB of free memory, recommending 640 KiB or more. It also requires the %TEMP% directory to have at least as much free disk space as the largest package you intend to install. Those are prerequisites, not performance targets. Check available memory before loading additional resident utilities, then check that %TEMP% names a writable directory on a disk with adequate space. The FreeDOS MEM /FREE command displays free conventional and upper-memory blocks; use its output to establish a baseline, but do not assume that every reported memory block is available to this particular program.

Plan the temporary workspace separately from the final install destination. A package that fits in the destination directory can still fail if the temporary directory is on a nearly full RAM disk or another small volume. If you cannot establish where %TEMP% points or how much space remains, defer the install instead of experimenting with a large package. On an actual 8086-era machine, first test with a small package in a backed-up installation or emulator snapshot.

Satisfy both network prerequisites

Remote repositories require two pieces that are easy to confuse: a loaded packet driver for the network adapter and a working WatTCP environment, including a valid wattcp.cfg. The packet driver presents the adapter interface; WatTCP provides the TCP/IP environment expected by this program. Load and verify the card-specific packet driver using its own documentation, then confirm its startup output and network attachment before testing package access. A driver for an incompatible adapter or incorrect hardware settings will not be repaired by changing a repository URL.

Do not substitute an mTCP configuration for the WatTCP requirement. mTCP is a separate DOS TCP/IP stack with its own programs and configuration conventions; the FDNPKG16 0.99.8254f manual specifically names WatTCP and wattcp.cfg. A system can use mTCP for other network utilities and still need a separate working WatTCP setup for this package manager. The exact adapter, software interrupt, and WatTCP settings depend on the driver and hardware in use, so this article does not prescribe a universal packet-driver command line or invented wattcp.cfg template.

Confirm which configuration the binary reads

Keep a copy of the configuration sample that belongs to the pinned release, then point FDNPKG16 at that copy if the default is not appropriate. The manual says the default is %DOSDIR%\BIN\FDNPKG16.CFG, and the override variable is literally named FDNPKG16.CFG:

SET FDNPKG16.CFG=C:\FDOS\BIN\FDNPKG16.CFG
FDNPKG16 dumpcfg

Replace C:\FDOS with the real FreeDOS path. dumpcfg prints the configuration loaded by the program; use it to confirm effective directives after setting the variable. It is an inspection command, not proof that the file is secure or that every configured repository is trustworthy.

There is a version-specific trap in the pinned sample: its inherited comments still call the file FDNPKG.CFG and describe the original program’s default path and environment variable. Those comments conflict with the 0.99.8254f manual’s runtime contract. Follow the pinned manual’s FDNPKG16.CFG name and use dumpcfg to confirm the loaded settings; do not select a file path from the stale comments alone.

Review the sample’s active REPO lines and dir destinations before installing anything. The sample config maps package categories to directories such as C:\NET and %DOSDIR%\links; paths must make sense for the target, have room, and not redirect files into a data directory by accident. The sample also includes mapdrives, a special drive-letter remapping option intended for install-time mismatches. Leave it commented unless you have a specific, tested reason to remap. To narrow the first test, retain only the intended official repository line and the destinations you actually need. The sample’s proxy directives are documented for HTTP repositories only; do not expect them to configure Gopher traffic.

Stage an install instead of updating everything

Start with commands that inspect repository results and local state. FDNPKG16 documents search, vsearch (which also displays source repositories), notinstalled, listlocal, checkupdates, and download (which downloads without installing). A conservative first pass might be:

FDNPKG16 dumpcfg
FDNPKG16 vsearch nasm
FDNPKG16 listlocal
FDNPKG16 checkupdates

Use a real package name from the configured repository in place of nasm if needed. Check that the selected package and source are expected before making a change. download is a useful non-installing action, but the pinned manual does not define a universal output path or describe it as a cryptographic verification step. Do not treat a download-only command as a dry-run of installation or as a security approval.

For a controlled test, take a backup or emulator snapshot, verify memory and %TEMP% capacity, then install one reviewed package by name or a trusted local ZIP path. The documented syntax accepts a local ZIP as well as a repository package:

FDNPKG16 install D:\STAGE\PACKAGE.ZIP
FDNPKG16 listfiles PACKAGE
FDNPKG16 listlocal

Substitute the actual archive path and package name. listfiles reports files owned by the named installed package; retain that record when investigating conflicts. The manual says FDNPKG16 checks packages and refuses ones that appear invalid, but that structural preflight is not documented as a transaction or rollback guarantee. Do not interrupt a write in progress or assume a failed install left the filesystem unchanged; inspect the result and restore from the backup if necessary.

For upgrades, review checkupdates first and then name the specific package in update. The manual says update without an argument updates all packages, so avoid it until you have reviewed the full change set and have a recoverable backup. If a package must remain at its current version, hold and unhold are available, but record why the hold exists and revisit it deliberately rather than letting it become invisible drift.

Treat HTTP and Gopher repositories as untrusted input

The pinned manual supports remote HTTP or Gopher repositories, and the sample configuration uses plain http:// URLs for its FreeDOS 1.4 mirrors. The manual and sample do not document TLS certificate validation, package signatures, or a cryptographic authenticity check. FDNPKG16’s package checks can reject an archive that looks invalid; they do not prove who supplied a valid-looking ZIP. Assume remote metadata and packages could be modified in transit or at the source.

For a low-risk experiment, use a disposable machine or image and restrict the configured repositories to the intended source. For a system with valuable data, acquire the ZIP over a separately trusted channel, verify it against a digest or signature published through an independent trusted path when one is available, then transfer it locally and use the ZIP-path form of install. A checksum copied from the same unauthenticated repository is not an independent trust check. Keep the original archive and notes until the installed files have been tested; do not treat successful extraction as proof of provenance.

Diagnose by layer

If repository access fails, verify the adapter and loaded packet driver first, then the WatTCP configuration and wattcp.cfg, then the repository URL and configuration actually shown by dumpcfg. If search works but installation fails, inspect %TEMP% capacity, the target dir mappings, package suitability for the CPU, and the package’s own documentation. When behavior differs from an older FDNPKG guide, check whether that instruction uses the original command or stale config-file comments before applying it to FDNPKG16.

The practical boundary is simple: the 16-bit executable, packet driver, WatTCP setup, temporary storage, repository configuration, and package trust decision are separate parts of the workflow. Verify each before the first write, and keep a recoverable copy of the target system while evaluating this pre-1.0 release.

Related:

Sources: