SAGE@LL.ARPA (12/28/88)
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.