oferp@SHUM.HUJI.AC.IL (Ofer Porat) (11/02/90)
In article <1990Oct31.162910.6997@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov ( Kaleb Keithley ) writes: >In article <schraudo.657337667@beowulf> 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 <standard.disclaimer> My opinions alone Ofer Porat E-mail: oferp@shum.huji.ac.il
lsalomo@hubcap.clemson.edu (lsalomo) (11/02/90)
>>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. What? Don't try and tell me that the loader keeps the relocation table in memory after it has loaded the program!...Is that what you meant? The way I understand it, and the way MY loader works, is to read the header, allocate a block of memory to read the relocation table into memory (who's size is in the header), then read the code itself into another block of allocated memory. Finally, it goes through the relocation table, patching up the code, deletes the relocation table, and jumps to the starting address. Cheers, Q - the "Q"uestor for knowledge (, a degree, etc.) lsalomo@hubcap.clemson.edu ibmman@clemson.clemson.edu ============================================================================= "Gee Wally, I think there's something wrong with the Beaver." =============================================================================