Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!oddjob!hao!noao!mcdsun!sunburn!gtx!edge!doug
From: doug@edge.UUCP (Doug Pardee)
Newsgroups: comp.sys.ibm.pc
Subject: Re: reducing size of exe files
Message-ID: <816@edge.UUCP>
Date: Fri, 12-Jun-87 13:42:46 EDT
Article-I.D.: edge.816
Posted: Fri Jun 12 13:42:46 1987
Date-Received: Sat, 20-Jun-87 18:39:42 EDT
References: <4044@amd.UUCP> <3320018@hpsrlc.HP.COM> <2723@mtgzz.UUCP> <1314@dataio.Data-IO.COM>
Organization: Edge Computer Corporation, Scottsdale, AZ
Lines: 37
Summary: EXEPACK application and bugs

<>It's my understanding that the .EXE format is a standard one that LINK
<>produces. I have tried EXEPACK on several programs not created by me
<>with no problem. If someone has actually had trouble using EXEPACK on
<>other programs I'd be interested to hear about it.
<
<I have trouble with EXEPACK now and then. It occasionally produces an
<EXE file that promptly crashes. Adding or removing a few bytes of code
<from an object module causes it to start working again. Using the linker
<with the /E switch exhibits the same results (must use the same code).

EXEPACK does work on nearly all .EXE files.  It performs two kinds of
compression: strings of duplicate bytes (usually zeroes) are compressed,
and the relocation table information is cut almost in half by replacing
the 4-byte "far pointers" with 16 groups of 2-byte "near pointers".  The
code to unpack the file is added to the end of the file.  The linker's
/E switch is indeed the same as running EXEPACK.

EXEPACK has 3 bugs to my knowledge.  #1 is probably unimportant: the
unpacking code destroys AX, which CP/M type programs expect to contain
"good/bad disk drive ID" flags for the first two command line parameters.
I don't know of any programs which expect said flags to be intact.

#2 is that it fails to update the EXE file header field which says how
much more memory is needed besides the size of the (now smaller) EXE file
code.  Unless you're loading in really tight memory, this probably doesn't
matter.

#3 is that it is possible for certain small programs, with few duplicate
bytes, to have the packed code be larger than the unpacked code.  The
unpacker can't deal with this and will crash when you try to run the
program.  Note that this refers to the packed *code* and not the .EXE file
itself; the relocation table is not part of the code in an unpacked file,
but it is part of packed code.  EXEPACK depends on saving enough code space
from compressing duplicate bytes to make up for the relocation table and
the unpacking code.
-- 
Doug Pardee, Edge Computer Corp; ihnp4!mot!edge!doug, seismo!ism780c!edge!doug