PC NetHack Support Utilities
		     ============================
		     Last revision: 1991January29

This file contains documentation for the NetHack MS-DOS support
utility EXESMURF.EXE.  This utility examines and modifies the load
parameters of an .EXE file and can be used to split .OVL files off a
monolithic overlaid executable using ovlmgr.

EXESMURF
--------
exesmurf FILENAME[.EXT] /v
exesmurf FILENAME[.EXT] /minN
exesmurf FILENAME[.EXT] /maxN
exesmurf FILENAME[.EXT] /l
exesmurf FILENAME[.EXT] N... [/pPATTERN]

The programme exesmurf is basically a reimplementation of Microsoft's
EXEMOD utility.  However, this incarnation is one that is
"overlay-aware" (as they say).  It will provide the user with
information about the executable and its overlays, and allow you to
modify the executable's parameters and overlay locations.

This program is made available for all users who were not graced with a
release of EXEMOD in their Microsoft product, or who need the
additional functionality it provides.

/v.
If exesmurf is invoked with a filename as argument, optionally
followed by a /v, the filename's exeheader is listed for your viewing
pleasure, along with the headers of any Microsoft-format overlays the
file may contain.  The listing is verbose; if there are many overlays
you will want to redirect the output.  Note that the redundancy in the
output listing largely reflects redundancy in the file structure.

/minN, /maxN, /stackN.
Exesmurf may also be used to modify the "minalloc", "maxalloc" and
"stack" allocation parameters of the executable file.  This can be
accomplished with the /min, /max, and /stack flags respectively.  Any
arguments to these flags should be *immediately* followed by a decimal
number N.  Note that this is inconsistent with the arguments to EXEMOD
which takes hex numbers, and *needs* a space between the flag and the
number.

/l.
The /l option requests a version of the /v listing (see above) in
which the information about overlays is very much compressed; only
their decimal file and load sizes are given, in a multi-column format.
The resulting display will generally fit on a single screen.  This
turns out to be very useful when contemplating appropriate parameters
for the overlay splitting operation described next.

N... [/pPATTERN].
The overlay-unpacking function of exesmurf is invoked by following the
filename argument by a sequence of decimal numbers.  Each of these
numbers is an overlay number at which a new external overlay file is
to be started.  The main executable file will keep its old name after
the overlays have been unloaded; the original input file will be
retained, with its extension changed to .BAK.  By default, the output
files will be derived from the input file name by appending a
discriminating character (in sequence, 0, 1, ..., 9, a, b, ..., z) to
the basename and changing the extension to .OVL; but if the basename
is a full 8 characters long, the discriminating character will replace
the last character instead.  This default is chosen for compatibility
with ovlmgr.  The default may be overridden with the /p option, which
specifies a file PATTERN - a file name, possibly complete with
extension, containing one or more ? characters (* is not allowed),
which will be replaced by discriminating characters.  If there is
exactly one questionmark, it will be replaced by a digit or letter in
the sequence described above, but if more than one questionmark
appears a decimal numbering scheme is used instead.
	Note that the numeric arguments are overlay numbers, not
indices, and they indicate the starting overlays of files.  This
permits us to manipulate files in which (for some reason) the overlays
are not stored in ascending order, but it does mean that if a
mentioned overlay does not exist in the original file, no new overlay
file will be started.  This is a realistic risk, since the Microsoft
linker does not seem to generate overlays at all if there is no actual
code generated into the segments in question.
	Note further that this operation can be reversed with the DOS
copy/b operation, always supposing that it works as documented in your
release of the operating system: the overlays are simply moved
page-by-page to the external files.
	No guarantees are made as to how this programme will behave if
there is debug information or other strangeness stored after the last
overlay in the file.

Whenever exesmurf is invoked, the extension .EXE is assumed for the
file if no extension is given.  Other extensions are probably only
meaningful for examining overlay files.
----------------------------------------------------------------------
Stephen P Spackman                       stephen@estragon.uchicago.edu
----------------------------------------------------------------------