Date   : Tue, 27 Dec 1988 13:11:03 EDT
From   : <SAGE@LL.ARPA>
Subject: Finding the Z Environment

   Mark Wilson's proposed method for determining the Z3ENV address by
scanning high memory is a suggestion in the right direction, but it ignores
some very important details.  A program I tried using recently failed on my
system because it used the very scheme Mark describes.
 
   ENV+3 is not the only place in memory where the string "Z3ENV" may occur. 
On my system I have a directory with that name (it's where I work on the
source code for the ENV module).  A user might have loaded that name into
one of the four system file names in the message buffer.  There might be a
reference to "Z3ENV" in a pending command line in the multiple command line
buffer.  The disk deblocking buffers in the BIOS might happen to contain
this string if a file had been accessed that contained that text.  In short,
there are quite a few other places where such a string might appear.
 
   ONE CANNOT ASSUME THAT ANYTHING ONE IS LOOKING FOR IS UNIQUE!  It is
always necessary to validate the address that one thinks is the ENV.  This
can be done by looking at the word in offset 1BH in the assumed ENV
descriptor.  That is where the ENV address itself is stored in the ENV. 
This might have seemed redundant; after all, if you know where the ENV is,
why do you need to look it up in the ENV?  This is one good reason.
 
   So, the strategy comes down to this.  Determine the range of memory to be
scanned and the direction.  Then scan for the string "Z3ENV".  When it is
found, assign an address 3 lower as the tentative ENV address.  Add 1BH to
this, and see if the word there is the same ENV address.  If it is, you can
be pretty sure that you have the ENV.  If not, continue the scan where you
left off last time.
 
   There are probably various arguments that could be made as to what range
of memory should be scanned and in which direction.  Joe Wright has
experimented with putting Z-System modules (notably the FCP) in an RSX that
lives not only below the BIOS but below the command processor.  To cover
such a case, the lower bound in memory should probably be the bottom of
protected memory, namely, the address stored at location 0006H.  From here
one would have to scan up all the way to FF03H (the highest possible
location for a two-record ENV descriptor).  Scanning up is probably safer
than scanning down, I think, since it would be less likely to hit memory-
mapped I/O before finding the ENV.
 
   I suppose there is always a slight chance that this procedure will detect
the image of a different ENV descriptor whose file was examined and happens
to be in the BIOS deblocking buffer.  It would be hard to prevent this kind
of problem.  That memory image would, indeed, pass every test for an ENV
module since it is, in fact, such a module.  However, this would be unlikely
in general and virtually impossible if one has just loaded a transient
program, since its code would be in the buffer.