FreeDOS LOADFIX: Why Loading Above the First 64 KiB Can Help

LOADFIX is a compatibility wrapper for old DOS programs that fail when loaded at the bottom of memory. FreeDOS help describes it as loading a program above the first 64 KiB and then running it; it also calls out “Packed file corrupt” as a situation where that placement may help. The command does not repair an executable, add memory, or guarantee compatibility. Its effect is deliberately narrow: change the child’s initial memory placement so a program with a low-memory-sensitive assumption may run.

The FreeDOS command help documents the shell syntax and behavior, but command implementations can vary by shell and release. Before deploying a batch file, inspect the help available in the target system and confirm that the active command interpreter provides LOADFIX. Do not assume a command found in one DOS shell is a kernel service available to every DOS-compatible environment.

What problem does LOADFIX target?

Some historical executables, including some packed programs, behaved incorrectly when their initial load image began in the first 64 KiB of conventional memory. A tool that loads the child above that region can avoid the problematic placement. This is a workaround for a program-specific assumption, not a general optimization technique and not a fix for corrupt media, damaged executable headers, insufficient memory, or a bad decompressor.

The distinction matters when diagnosing. If a packed file reports a corruption error, first verify the file’s integrity, transfer mode, archive extraction, and exact executable version. Then retrying through LOADFIX is a low-risk diagnostic if the target FreeDOS shell supports it. If the program still fails, stop attributing the issue to load placement and continue with evidence from the executable and memory map.

LOADFIX consumes address space to shift the child upward. In conventional-memory-constrained systems, that can make another program fail sooner. It does not free conventional memory, move arbitrary code into upper memory, or increase the largest available block. Use MEM or another trusted memory-reporting tool before and after launch to observe the actual layout, rather than assuming the wrapper is cost-free.

Use the documented command form

The FreeDOS help syntax is:

LOADFIX [drive][path]filename [options]

For example, with a hypothetical program:

LOADFIX C:\TOOLS\LEGACY.EXE /SAFE

/SAFE is only an example argument; it is passed to the child and is not a LOADFIX switch. Confirm the real program’s options separately. The path should identify the intended executable explicitly during diagnosis so that PATH, current-directory precedence, and similarly named files cannot select a different copy.

If invoking from a batch file, quote paths only according to the active command interpreter’s syntax and test arguments that contain spaces if the shell supports them. Record the exact command line, working directory, executable checksum/version, shell, and memory report. A successful launch through LOADFIX does not prove the program’s later memory accesses are safe; exercise the behavior that originally failed.

A disciplined troubleshooting sequence

Reproduce the failure by launching the executable directly and preserve the exact message.
Verify the file is the intended build and is not truncated or damaged.
Inspect available conventional memory and other resident drivers or TSRs.
Confirm LOADFIX exists in the target shell and read its local help.
Retry the explicit executable path through LOADFIX, then run a focused functional test.
Compare memory availability and failure behavior with the direct launch.

Change one factor at a time. Do not combine LOADFIX with several unrelated memory-manager switches and then claim the result proves which option mattered. If the program only works after moving drivers, reducing buffers, or disabling caches, isolate those changes separately.

Shell and version boundaries

FreeDOS distributes multiple command interpreters and components. The help page notes that LOADFIX is internal to COMMAND.COM; the precise shell, build, and command behavior on an installed system should be verified locally. A different shell may implement a command with the same name differently or omit it. If a batch file is distributed to users, document the expected shell and give a direct-launch fallback rather than assuming every DOS environment includes the same internal command.

Keep the child program’s exit status visible to the surrounding script and verify the active shell’s errorlevel semantics. Wrappers can affect how errors are propagated. A batch file that prints “success” because LOADFIX itself was found does not establish that the child completed successfully. Test both the wrapper’s launch failure and the program’s own nonzero exit behavior.

Common misdiagnoses

Do not use LOADFIX as a substitute for LOADHIGH or an upper-memory manager. Those features have different purposes and constraints. Do not infer that “above first 64 KiB” means the whole program resides outside conventional memory; it still runs in DOS address space. Do not keep increasing memory padding when the real issue is a bad file, an unsupported CPU instruction, or a device conflict.

Do not patch an executable to imitate LOADFIX placement without understanding its relocation model and loader requirements. EXE files carry header information about image size, relocations, and minimum/maximum allocation. COM files have different loading conventions. Modifying the binary can break it or invalidate provenance and makes reproduction harder.

Verification and rollback

Test on a disposable boot configuration with the same FreeDOS kernel, command interpreter, memory managers, and drivers as the affected machine. Record direct and wrapped runs. Check that the program’s important workflows complete, not merely that the splash screen appears. If the workaround reduces memory below what another application needs, remove it from that launch path and seek a program update or a better-supported execution environment.

Keep the workaround scoped to the one executable. Avoid adding LOADFIX globally to AUTOEXEC or wrapping unrelated programs. In a support note, label it as a compatibility workaround and include the known application version and environment. That prevents a temporary workaround from turning into a mysterious permanent rule.

Measure the workaround instead of guessing

Capture a baseline memory report at the same boot point before comparing direct and wrapped launches. Conventional memory changes as drivers, TSRs, environment blocks, and shells load, so results from different boot configurations are not comparable. Record the largest available block as well as total free conventional memory: many DOS programs need one contiguous allocation, and a large total split into small holes can still be unusable.

If LOADFIX makes one executable start but causes another to fail, that is evidence of a resource tradeoff, not a contradiction. The first program may depend on a different initial segment placement; the second may need a larger contiguous block. Keep separate launch entries and document why only the one target is wrapped. If the application has a supported patched release or a maintained replacement, prefer that over a permanent loader workaround because the workaround does not repair assumptions made after startup.

When testing arguments, compare the child’s observed command line where possible and include a path containing spaces only if the active shell supports the required quoting syntax. Test return codes with both a successful child and a deliberate failure. A script should preserve the child’s result and must not convert “command interpreter found LOADFIX” into a false success message. Finally, repeat the test after rebooting into the documented configuration; transient memory layout can make an apparently deterministic workaround depend on unrelated TSR load order.

Operational rule

LOADFIX changes initial placement; it does not fix arbitrary executable corruption or create memory. Verify the command exists in the installed shell, launch the exact intended file, measure the memory tradeoff, and test the application beyond startup. If the symptom does not specifically match low-memory placement behavior, treat LOADFIX as an experiment rather than as the diagnosis.

Related:

Sources: