bolo@uwvax.UUCP (05/28/87)
I'm looking for utilities that will reduce the size of .EXE
files produced by either Quick Basic or Turbo Basic.
Some company has such a thing for Turbo Pascal, but doesn't have it
for anything else.
It can be either public domain, or a commercial product.
(A friend in the Engineering Mechanics department wants to put
more executables on a disk, for a computerized statics teaching aide
that the department uses.)
Either mail or the net is just fine.
tnx in advance
bolo
Josef Burger
University of Wisconsin Madison Computer Systems Lab
arpa: bolo@spool.wisc.edu
uucp: {ihnp4|seismo|most_anything}!uwvax!bolonathan@mit-eddie.UUCP (05/29/87)
In article <3624@spool.WISC.EDU> bolo@spool.WISC.EDU (Joe Burger) writes: >I'm looking for utilities that will reduce the size of .EXE >files produced by either Quick Basic or Turbo Basic. A utility called exepack which comes with the Microsoft C compiler might do what you want. It's never actually packed my .exe files very much, but it always does at least a little bit. I don't recall it saying that the .exe files used with it had to come from the C compiler, so it might work for you. -- Nathan Glasser nathan@mit-eddie.uucp (usenet) fnord nathan@xx.lcs.mit.edu (arpa) "A tribble is the only love that money can buy."
markg@amd.UUCP (Mark Gorlinsky) (05/29/87)
In article <3624@spool.WISC.EDU> bolo@spool.WISC.EDU (Joe Burger) writes: >I'm looking for utilities that will reduce the size of .EXE >files produced by either Quick Basic or Turbo Basic. I have a program called EXE2COM that changes a EXE file to a COM file. It does this by removing the EXE related header, packing the file, and putting on a new header. The only limitation is that the EXE file has to <64K. -- Mark Gorlinsky - AMD Processor Products Division/APPS SQA UUCP: {decwrl,ihnp4,allegra}!amd!markg AT&T: (408) 982-7811 DISCLAIMER: My opinions are mine, not my employers.
rosen@mtgzz.UUCP (t.rosenfeld) (06/01/87)
In article <4044@amd.UUCP>, markg@amd.UUCP (Mark Gorlinsky) writes: > In article <3624@spool.WISC.EDU> bolo@spool.WISC.EDU (Joe Burger) writes: > >I'm looking for utilities that will reduce the size of .EXE > >files produced by either Quick Basic or Turbo Basic. > > I have a program called EXE2COM that changes a EXE file to a COM file. > It does this by removing the EXE related header, packing the file, and putting > on a new header. > > The only limitation is that the EXE file has to <64K. Microsoft has a program EXEPACK that comes with their compiler that uses some scheme to pack any .exe file. This works on files >64K also. I think it packs nulls and removes debug and symbol table info and the like. -- Tom Rosenfeld @ AT&T Information Systems Labs, Middletown, NJ (201) 957-5867 UUCP: {harpo,ihnp4,burl,akgua}!mtgzz!rosen Disclaimer: I don't claim anything.
darrylo@hpsrlc.HP.COM (Darryl Okahata) (06/02/87)
In comp.sys.ibm.pc, rosen@mtgzz.UUCP (t.rosenfeld) writes: > > In article <4044@amd.UUCP>, markg@amd.UUCP (Mark Gorlinsky) writes: > > In article <3624@spool.WISC.EDU> bolo@spool.WISC.EDU (Joe Burger) writes: > > >I'm looking for utilities that will reduce the size of .EXE > > >files produced by either Quick Basic or Turbo Basic. > > > > I have a program called EXE2COM that changes a EXE file to a COM file. > > It does this by removing the EXE related header, packing the file, and putting > > on a new header. > > > > The only limitation is that the EXE file has to <64K. > >Microsoft has a program EXEPACK that comes with their compiler that uses >some scheme to pack any .exe file. This works on files >64K also. ^^^ Microsoft claims that EXEPACK will work ONLY with code generated by their compilers; they do not claim that it will work with anything else. >I think it packs nulls and removes debug and symbol table info and the like. > >-- >Tom Rosenfeld @ AT&T Information Systems Labs, Middletown, NJ > (201) 957-5867 > UUCP: {harpo,ihnp4,burl,akgua}!mtgzz!rosen >Disclaimer: I don't claim anything. >---------- -- Darryl Okahata ucbvax!ucbcad!ames!hplabs!hpcea!hpsrla!darrylo <== best path hplabs!hpcea!hpsrla!darrylo <== alternative CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
jpn@teddy.UUCP (06/04/87)
>>Microsoft has a program EXEPACK that comes with their compiler that uses >>some scheme to pack any .exe file. This works on files >64K also. > ^^^ > Microsoft claims that EXEPACK will work ONLY with code >generated by their compilers; they do not claim that it will work with >anything else. > >>I think it packs nulls and removes debug and symbol table info and the like. 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). Anyway, it is my experience that EXEPACK works with 95% of the programs I have tried it on, although it is only infrequently that the compression is worthwhile (i.e. saves multiple blocks on my hard disk). I ALWAYS save a copy of the original program before PACKing, just in case there is a problem.
jsm@vax1.ccs.cornell.edu (Jon Meltzer) (06/05/87)
In article <2711@mtgzz.UUCP> rosen@mtgzz.UUCP (t.rosenfeld) writes: > >Microsoft has a program EXEPACK that comes with their compiler that uses >some scheme to pack any .exe file. This works on files >64K also. >I think it packs nulls and removes debug and symbol table info and the like. > Which Microsoft compiler? C?
rosen@mtgzz.UUCP (t.rosenfeld) (06/05/87)
In article <3320018@hpsrlc.HP.COM>, darrylo@hpsrlc.HP.COM (Darryl Okahata) writes: > In comp.sys.ibm.pc, rosen@mtgzz.UUCP (t.rosenfeld) writes: > > > > In article <4044@amd.UUCP>, markg@amd.UUCP (Mark Gorlinsky) writes: > > > >Microsoft has a program EXEPACK that comes with their compiler that uses > >some scheme to pack any .exe file. This works on files >64K also. > ^^^ > Microsoft claims that EXEPACK will work ONLY with code > generated by their compilers; they do not claim that it will work with > anything else. > 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. -- Tom Rosenfeld @ AT&T Information Systems Labs, Middletown, NJ (201) 957-5867 UUCP: {harpo,ihnp4,burl,akgua}!mtgzz!rosen Disclaimer: I don't @mimStanw .lsewm
bright@dataio.Data-IO.COM (Walter Bright) (06/08/87)
In article <2723@mtgzz.UUCP> rosen@mtgzz.UUCP (t.rosenfeld) writes:
<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).kneller@cgl.ucsf.edu (Don Kneller%Langridge) (06/09/87)
In article <1314@dataio.Data-IO.COM> bright@dataio.UUCP (Walter Bright) writes: >In article <2723@mtgzz.UUCP> rosen@mtgzz.UUCP (t.rosenfeld) writes: ><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). I don't know if my previous posting got out about problems with EXEPACK. One thing I've noticed is EXEPACK can reduce the maximum number of paragraphs (of memory) below the minimum number. This happens when you've linked with linker flag /CP:1 (which sets the maximum number of paragraphs equal to the minimum number), then EXEPACKed. This can cause your system to hang when allocating memory or trying to exec() a subprocess. The solution to the problem is to use EXEMOD to fix the maximum number. "exemod foo.exe /max 1" will reset the maximum number to be the equal to the minimum number again. ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller ARPA: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
bright@dataio.Data-IO.COM (Walter Bright) (06/10/87)
In article <10234@cgl.ucsf.EDU> kneller@socrates.ucsf.edu.UUCP (Don Kneller) writes: <In article <1314@dataio.Data-IO.COM< bright@dataio.UUCP (Walter Bright) writes: <<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). < <One thing I've noticed is EXEPACK can reduce the maximum number of <paragraphs (of memory) below the minimum number. This happens when <you've linked with linker flag /CP:1 (which sets the maximum number of <paragraphs equal to the minimum number), then EXEPACKed. I am not using the linker flag /CP:1
doug@edge.UUCP (Doug Pardee) (06/12/87)
<>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