FC and COMP on FreeDOS: Binary Verification Versus Text Diff

FreeDOS includes two related file-comparison tools with different strengths. COMP compares files as binary data and reports differing bytes. FC can compare either bytes or text lines and has more options for recursive sets, context, and exit-status handling. The critical decision is to choose an explicit mode. A text comparison may normalize or interpret line-oriented data; a binary comparison tests byte-for-byte identity. Neither command authenticates the source, repairs a transfer, or replaces an independently trusted checksum.

Pick the tool based on the question

Use FC /B when the question is “Are these two files byte-for-byte equal?” That is the right baseline for copied executables, archives, disk images, configuration backups, and any file where newline or whitespace differences are meaningful. FreeDOS documents binary output as offsets and differing byte values in hexadecimal, with printable character equivalents where possible.

Use FC /L when the question is “How do these two text files differ by lines?” Text mode is useful for comparing configuration or source files where a line-oriented report is easier to read than a byte offset. But text mode can obscure whether differences are due to line endings, spacing, or content, and FreeDOS FC documents a limit of the first 32,765 lines in text comparison. For a final exact copy check, run /B even if /L helped explain a difference.

COMP is useful for a simple binary comparison and can compare single files, wildcard sets, or files in directories. Its documentation says a directory argument applies to the files in that directory, not its subdirectories. Do not assume that COMP recursively walks a tree. For a recursive same-pattern check, FC’s /S is the relevant switch, but its recursion follows corresponding directory names and needs carefully matched path patterns.

Explicit commands for one pair

The simplest reliable byte comparison names both files and uses the binary switch:

FC /B C:\SOURCE\IMAGE.BIN D:\COPY\IMAGE.BIN

If they match, the command reports no differences and returns zero according to FreeDOS documentation. A mismatch returns one; invalid syntax, missing files, or open errors use other nonzero codes. Keep both paths explicit so current-drive and current-directory state cannot silently select a different file.

For a line-oriented configuration review, use:

FC /L /N C:\CONFIG\FDCONFIG.SYS D:\BACKUP\FDCONFIG.SYS

/N includes line numbers. If spaces or tabs are intentionally insignificant, /W packs whitespace for text comparison, but that changes what differences appear. Do not use /W to verify a file copy where bytes matter. FC /C ignores letter case, which is appropriate only if case is semantically irrelevant for the particular text format.

Default modes and extension-based behavior

FreeDOS FC documents that it defaults to binary mode for common executable and object extensions such as .EXE, .COM, .SYS, .OBJ, .BIN, .DLL, and .LIB. Do not rely on the extension heuristic for less common formats. A file named DATA.DAT can be binary even if FC’s default is text, and a misleading extension can select a mode you did not intend. Make /B or /L explicit in scripts and runbooks.

FC /B limits the number of binary differences it displays by default; the documented /M switch changes that limit, and /M0 means unlimited differences. A limited report can still establish that the files differ, but it may not show every differing offset. If the only need is a pass/fail check, /Q suppresses the list of differences. Preserve the return code and output in a log, and remember that a zero result from one pair does not prove the rest of a directory tree matched.

COMP has a numeric /n-style option for the maximum differences it prints per file, and its default depends on whether a single file or a multiple-file comparison was requested. The exact display limit is not a guarantee that all differences were searched if the operation stopped because of an error. Use the installed COMP /? and FC /? for the build on the machine.

Wildcards and directory matching

Wildcards turn a two-file comparison into a set-matching problem. FC documents several forms: a directory can stand for all files in it; omitted second filenames may refer to the current directory; and paired wildcard paths compare matching names across locations. Those rules are useful for comparing a source directory with a copy, but can also yield an incomplete test if one side contains extra files or if the patterns do not align.

A scoped example for matching .TXT files in corresponding directories is:

FC /B /S C:\PROJECT\*.TXT D:\STAGE\*.TXT

Before interpreting success, separately enumerate both trees and check that the expected filenames are present on each side. FC /S scans corresponding subdirectory patterns; it is not a manifest generator and does not prove that unpaired extra files do not exist. Use the /U option to display unmatched filenames where appropriate, and inspect the command’s output rather than relying only on the first “no differences” line.

COMP’s wildcard behavior is less recursive: it handles files in the named directory but not their descendants. If a tree contains nested folders, run comparisons at each level or use FC with an explicitly understood /S pattern. Do not substitute a wildcard for an exact filename when the set could include temporary files, partial downloads, or alternate versions.

DOS names, long filenames, and path resolution

FreeDOS tools may run with or without DOSLFN or another long-filename provider. FC’s documentation says it uses long filenames automatically if the operating system supports them. That is not a promise that every file-comparison utility or every path parser on every DOS kernel has identical LFN behavior. If a name contains spaces or exceeds 8.3, confirm support with DIR, test the quoted path on harmless files, and consider using short aliases in automation.

DOS drive-relative paths can also surprise: C:FILE.TXT is resolved relative to the current directory stored for drive C, while C:\FILE.TXT is rooted at C. Prefer fully qualified rooted paths for repeatable comparisons. When using a batch file, print or log the paths before comparison and stop if either input is missing.

Batch exit codes without false success

FreeDOS FC documents return code 0 when files match, 1 when at least one pair differs, 2 for invalid command-line parameters, 3 for missing files, and 4 for open errors. Since DOS IF ERRORLEVEL n means greater-than-or-equal, check errors in descending order:

FC /B C:\SOURCE\FILE.ZIP D:\COPY\FILE.ZIP
IF ERRORLEVEL 4 GOTO OPEN_ERROR
IF ERRORLEVEL 3 GOTO MISSING_FILE
IF ERRORLEVEL 2 GOTO BAD_SYNTAX
IF ERRORLEVEL 1 GOTO DIFFERENT
ECHO Files match

The branches must exist later in the batch file, and the exact error levels should be verified against the installed FC version. Do not run another command that overwrites ERRORLEVEL before the checks. If processing many pairs, capture each result immediately and produce a summary that distinguishes mismatch from failure to compare.

Comparison is not authentication

If FC reports identical bytes, the two files are equal at the time of the read. That does not establish that either copy is authentic or uncorrupted relative to the publisher. For release media, compare a cryptographic digest to a checksum obtained through an independent trusted channel. For long-term archival, keep multiple copies on separate devices and periodically verify them. FC and COMP are helpful for local pairwise validation, not a provenance system.

A file can also change while a comparison is running if another program has it open for writing. Close installers, editors, and transfer processes first. Compare a stable copied snapshot rather than a live file being updated. If a storage medium produces read errors, stop repeating comparisons against the same failing device and image it through a recovery-oriented workflow.

Practical verification workflow

For a file copy: confirm the source path and expected size; copy to a separate destination; compare with FC /B; save the exit code; and, where available, verify an independently published digest. For a text configuration change: use FC /L /N to understand line changes, then preserve a backup before deployment. For directory trees: enumerate both sides, compare matching files with /S only after validating the pattern, and check for extras separately.

The most useful comparison is one whose scope and mode are explicit. A short command with rooted paths and /B gives stronger evidence than a complex wildcard command that no one can explain. When the file is valuable, record the tool version, command line, timestamps, and result so another operator can reproduce the check.

Related:

Sources: