Xref: utzoo comp.os.msdos.apps:726 comp.sys.ibm.pc.misc:4461
Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!wuarchive!emory!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!philapd!idcapd!robl
From: robl@idca.tds.PHILIPS.nl (R. Luursema)
Newsgroups: comp.os.msdos.apps,comp.sys.ibm.pc.misc
Subject: Re: Meaning of "Packed File Is Corrupt" Message??
Message-ID: <1068@idcapd.idca.tds.philips.nl>
Date: 6 Dec 90 15:53:25 GMT
References: <4e61a969.20b6d@apollo.HP.COM>
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 56

In article <4e61a969.20b6d@apollo.HP.COM> angelini@apollo.HP.COM (Bob Angelini) writes:
>
>I get the following error message on a 286 clone when I try to
>run several programs: Packed File Is Corrupt
>
>The programs (games and apps) run fine on another 286 system, so
>I know the software is OK. 
>
>Any ideas on what might cause this message??
>
>Bob Angelini


I stumbled once also over this problem...

Packed files are created by the Microsoft linker when using the 
exepack option. 
At load time the executable is unpacked.

In my case, the 'Packed file corrupt' message was only given under certain
circumstances.
The problem was tracked down to A20 GATE signal. This signal enables
Addressline 20 from the cpu to the outside world (memory). When A20 is
DIS-abled, the system mimicks the 8088/86 1 Mb address-space roll over.
This (hardware-) signal is a combination of two sources on the system I 
worked on. One is from the keyboard controller chip (8042) and is
generally used by protected mode (control) programs. The other is 
from a hidden/proprietary system IO port.
The first source is for compatibility and is rather slow, the second
is BIOS internal and fast.

The 'packed file corrupt' only occurred after some utility left the
fast A20 gate in the wrong state (A20-enabled).

The mystery was that it only occurred from the first command.com shell;
starting a second command.com, or starting from NortonCommander, or
running from a debugger made the problem go away.

Since the program is already unpacked when loaded by the debugger (it
did cot complain while loading), the problem could not be traced
using a debugger  :-(

What I still don't know is WHY the unpacking (code added to the program
by the linker) code is sensitive to the enabling/disabling of A20?

Is there somebody on the net who can enlighten me?

Rob.
#---------------------------------------#       ______
# Rob Luursema,   BS-HW,  V1b2 ext 2246 #      /____ / organized
# Philips Information Systems Apeldoorn #     /____ / like the 
# Domain:      robl@idca.tds.philips.nl #    /____ / tower of
# UUCP:           ..!hp4nl!philapd!robl #   /____ / pisa ...
#include <std/disclaimer>               #  /____ / 
#---------------------------------------# ========
 A good workman is known by his tools