Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!ucsfcgl!socrates.ucsf.edu!kneller
From: kneller@socrates.ucsf.edu.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Bug in EXEPACK (was: reducing size of exe files)
Message-ID: <10230@cgl.ucsf.EDU>
Date: Thu, 4-Jun-87 19:46:18 EDT
Article-I.D.: cgl.10230
Posted: Thu Jun  4 19:46:18 1987
Date-Received: Sat, 6-Jun-87 10:07:12 EDT
References: <4044@amd.UUCP> <3320018@hpsrlc.HP.COM> <4064@teddy.UUCP>
Sender: daemon@cgl.ucsf.edu
Reply-To: kneller@socrates.ucsf.edu.UUCP (Don Kneller)
Organization: UCSF Computer Graphics Lab
Lines: 24

In article <4064@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
>EXEPACK will PACK any .exe file, but the result may not work properly.
>EXEPACK may append a run-time initialization module, which allows EXEPACK
>to remove any large initialized buffers from the .exe image.  This appendage
>apparently clobbers some of the registers that the "exec" call sets up,
>but which MS-C does not need.  (Sorry, I don't have details).

I don't think the problems when using EXEPACK and exec() has anything to
do with registers.  In case you've never encountered this problem,
EXEPACKing a program that also has an exec() can cause the program to
"go into left field" when the exec() is called.

I believe the problem is a bug in EXEPACK which reduces the maximum
number of paragraphs (of memory) the program uses to a value less than
the minimum number of paragraphs.  This is wrong.

You can use "exemod foo.exe /max 1" to restore the maximum number to be at
least as large as the minimum.  Also you can use "exemod foo.exe" to
examine the number of paragraphs being used.
-----
	Don Kneller
UUCP:	...ucbvax!ucsfcgl!kneller
ARPA:	kneller@cgl.ucsf.edu
BITNET:	kneller@ucsfcgl.BITNET