From MS-DOS help for the LOADFIX command:

Some programs will display the "Packed file corrupt" message when all or a portion of the program has been loaded in the first 64K of conventional memory and cannot run successfully.

So one uses LOADFIX in order to fix that. Why does this error even occur? What's so special about these first 64K?

1 Answer 1


In short, it prevents a code bug from triggering in some executables compressed by Microsoft EXEPACK.

Programs themselves are supposed to work at any address, but these executables are packed with Microsoft EXEPACK utility to make compressed executable that is smaller than the original uncompressed executable.

The EXEPACK utility decompression routine had a bug in it, which failed to decompress the data into memory when loaded into too low address.

Which is why the decompressor in the compressed executable prints an error that the packed file is corrupt.

The decompressor will decompress the data by overwriting the compressed data in backwards, from high memory addresses down to low memory addresses. It un-intentionally could end up underflowing a segment register from 0x0000 down to 0xFFFF, which requires that memory addresses wrap around like in 8088/8086 that only have a 1MB address space.

Later CPUs that could access more memory needed motherboard support to enable or disable the wraparound to be compatible with existing 8088/8086 code, this is called the address line A20 Gate.

Later on people had 286 or 386 CPUs, enough memory for EMS and XMS memory support, DOS and driver TSRs loaded into HMA and UMB memory areas, so you are in a situation where 8088/8086 address wrapping must be disabled with Gate A20 and you have used only about 20KB of the first 64KB of memory, and then the EXEPACK loader stub bug will trigger when executing a compressed program.

That's why there is a program called LOADFIX shipped with some DOS versions, which ensures that the program to be executed is loaded above the first 64KB to avoid the EXEPACK bug.

So it's not really the first 64KB that are special, unless you consider the fact that on later machines the hardware may be in a mode which prevents software from accessing it through wraparound, be it intentional or unintentional from the software.

For further info, see Microsoft Knowledge Base article Q72360 ans OS/2 Museum article on EXEPACK and A20 Gate.

  • 3
    To add to your already good answer, on the 8086 each paragraph (16-byte chunk of memory) can be addressed with 4096 different segment bases, eg segmented addresses like 0002h:0000h == 0001h:0010h == 0000h:0020h. If A20 is masked off or on a real 8086, the chunks in the first 64 KiB - 16 Bytes can be addressed by wrapping around at 1 MiB using eg FFFFh:0030h == FFFEh:0040h == FFFDh:0050h and so on. On a 286+ with A20 (the 21st Address line) not masked, addresses that exceed 20 bits will actually access the HMA so the first 64 KiB - 16 Bytes have fewer aliases.
    – ecm
    Commented Oct 14, 2023 at 10:14
  • One might wonder why they just didn't ship a program to fix the bug in the actual exe instead... Commented Nov 1, 2023 at 22:36
  • 2
    @ThomasKjørnes I am sure there's reasons for that if you think. You would be altering files the user already has, maybe software or game bought was packed. Maybe an install media installer program, or the installed program is packed. Maybe these are already archived, or maybe on a read-only media, such as network drive or CD-ROM. I would want to keep my originals intact, if they check for tampering. It is simpler there's just an official loader tool which just has a manual that if programs fails to load try this loadfix program. Some DOSes seem to detect and hot-patch the bug without loadfix.
    – Justme
    Commented Nov 2, 2023 at 6:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .