🚀 go-pugleaf

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-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."