berg@cip-s04.informatik.rwth-aachen.de (Solitair) (07/11/90)
struct exeheader {unsigned magicnr, /*0x4d5a or 0x5a4d*/
remainder,pages;}
The third word in the EXE-header (exeheader.pages) is supposed to contain
the number of 512 byte pages the file occupies. Through some experimenting
I now seem to have figured out that you should calculate the number as follows:
Round UP the file size to the nearest multiple of 512, then divide by 512.
Could someone please confirm this?
Then there is this program "exepack": does anyone know how it determines
how much to add to the number of minimally-reserved-extra-pages? I'd like
to know, in order to be able to reverse the process (i.e. restore the file).
What I figured out about EXE-contained overlays:
Anything between the end of the load-image and the start of the next physical
512 page boundary in the EXE-file is garbage. In order to pack or compress
such a beast you have to remove everything after the end of the load-image
(which can be calculated to be at an offset of:
((exeheader.pages-1)<<9)+(exeheader.remainder?exeheader.remainder:512)-1 ).
Then pack or compress it as a usual EXE-file, then padd the file at the
end with whateveryoulike :-) until the file size is a multiple of 512,
then append everything you find in the original file at offset
(exeheader.pages)<<9 till the end of the original EXE-file.
Could someone knowledgeable please confirm this? Does this apply to
all the different kind of overlay linkers? (i.e. ms-link, plink, etc...)
--
Sincerely, |"I code it in 5 min, optimize it in 90
Stephen R. van den Berg. | min, because it's so well optimized:
uunet!mcsun!unido!rwthinf!cip-s01!berg | it runs in 5 only min. Actually, most
berg@cip-s01.informatik.rwth-aachen.de | of the time I optimize programs."