Path: utzoo!attcan!uunet!midway!ncar!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!SHUM.HUJI.AC.IL!oferp From: oferp@SHUM.HUJI.AC.IL (Ofer Porat) Newsgroups: comp.os.msdos.misc Subject: Re: when (and when not) to exe2bin? Message-ID: Date: 2 Nov 90 13:26:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: comp Organization: The Hebrew University of Jerusalem, Israel Lines: 58 In article <1990Oct31.162910.6997@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov ( Kaleb Keithley ) writes: >In article schraudo@beowulf.ucsd.edu (Nici Schraud olph) writes: >> >> I'd like to cram more onto my laptop's ramdisk by exe2bin-ing the .exe >> files ... [stuff deleted] >> > [stuff deleted] > >Furthermore, it's not that .COM files are "not-relocatable", it's that >relocation is not performed by the DOS run-time loader. EXE2BIN reads >the relocation table, and changes all function calls and data references >from absolute to relative (another reason why the program must be 64K or >less,) thereby eliminating the need for DOS to do it at run-time. An .EXE, >by contrast has a big table at the front of it, full of entries that the >run-time loader must resolve before the program has a snowballs chance >in hell of running. Wrong. EXE2BIN does not do anything with the EXE's relocation table, because the EXE is not supposed to have any entries in the reloc. table if it's to be converted to COM. All intra-segment memory references are relative on the 80x86, and since the COMable EXE must consist of only one segment, no inter-segment memory references (i.e. reloc. table entries) are allowed. > >Without trying to create any kind of hard rule, I'd suggest that EXE2BINing >programs should be left to the people who wrote them, and presumably >know whether they're eligible for EXE2BINing. > Exactly. EXE2BIN was not intended to be a 'compression' program for executables, but rather a program development tool. When someone writes a program, S/HE decides whether to make it an EXE or COM file. Deciding to make it an COM puts some constraints on the structure of the program, and the programmer takes this into account. You can't just EXE2BIN a program whose structure you know nothing about and hope that it works. It might even seem to work, and a few months later you'll discover problems with some little used parts of the program. If you want to compress executables in order to save (ram) disk space, I suggest you use one of the programs designed specifically for this purpose, such as Microsoft's EXEPACK (comes with their compilers, does null suppression I believe), or LZEXE (available as freeware, does Lempel-Ziv compression). >One more thought, I see no reason why the loader would put the relocation >table into memory, all my experience would lead me to believe that that >in fact is the case. So an EXE2BINed program should not use appreciably >less space in memory than its non-EXE2BINed cousin. > Of course it wouldn't take up less space in memory, but he was asking about its presence on RAM DISK. -- "... for Yossarian had decided to live forever, or die in the attempt ..." - Catch 22 #include My opinions alone Ofer Porat E-mail: oferp@shum.huji.ac.il