Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ltf From: ltf@killer.DALLAS.TX.US (Lance Franklin) Newsgroups: comp.sys.ibm.pc Subject: Re: Interactive BAT files: here's how Message-ID: <5797@killer.DALLAS.TX.US> Date: 13 Oct 88 09:03:03 GMT References: <8810040015.AA21729@decwrl.dec.com> <1317@micomvax.UUCP> <5137@watdcsu.waterloo.edu> Reply-To: ltf@killer.Dallas.TX.US (Lance Franklin) Organization: The Unix(R) Connection BBS, Dallas, Tx Lines: 75 In article <5137@watdcsu.waterloo.edu> dmurdoch@watdcsu.waterloo.edu ( D. Murdoch - Statistics ) writes: >In article <1317@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >>In MS C, setting environment variables is easy. You use the putenv library >>call, putenv("arg1=fred");, sets arg1 to "fred", whether arg1 existed >>before or not. >Doesn't putenv only affect the environment of the C program (and its children)? >The parent environment remains unchanged. To change it, you need one of >those routines that uses undocumented (i.e. unreliable) methods to find the >parent environment, and patches the changes in there. This is true...putenv only changes YOUR program's copy of the environment (and any child process's copy). However, it is possible to change the parent's copy, with a little work, at least under 3.xx. It involves... a) getting your process's psp address (available via the _psp external variable)...actually, this is an unsigned int that contains the segment that contains the psp. b) get the word at offset 16h in this segment...this is the segment that contains the parent process's psp. c) now get the word at offset 2ch of the parent's psp...this is a pointer to the parent's environment, or at least it is under 3.30. Under 3.10, if the parent is the copy of COMMAND.COM that was started up on bootup, this value, I have found, is always zero (but not under subsequent copies of COMMAND.COM, and not under 3.30...don't ask me why). In this case, the environment area seems to be at a constant offset of 0c1h paragraphs from the start of COMMAND.COM's psp. (1 paragraph = 16 bytes) Of course, I can't guarentee this...it works on my copy of 3.10 though. 3.30 seems to be much more logically constructed in this area. By the way, if there are more than one layer of process between your program and COMMAND.COM, you can repeat the process from (b) to (c) to follow the chain down...when you get to the closest COMMAND.COM, you'll find that the pointer to the parent's psp points to itself...don't bother to go further. :-) d) now that you have the address of the parent's environment, make a copy of it locally, do what you have to, and prepare to write it back to the original address...but first, make sure that you have enough space. The length of the environment's buffer is 1 paragraph before the start of the environment area + 3 bytes, and is a single byte indicating the number of paragraphs available for the environment. Don't try to write more than that number of paragraphs! You won't like the results! Incidently, this was the hardest bit of information for me to find... NOBODY documents this little bit of information, I had to bring up COMMAND.COM under codeview and trace thru a set command to find out what the length is. Oh, and by the way, 3.10 has another problem, I've found...no matter WHAT you do, you cannot get any more environment space for new invocations of COMMAND.COM than the amount of space that the current enviroment variables take (rounded to the next paragraph) plus 1 paragraph. Apparently, only the bootup copy of COMMAND.COM accepts the /E:xx parameter. If anybody knows a way to get around this, PLEASE let me know...right now, I do a set PAD= in AUTOEXEC.BAT, so I can free up some space when I need it...not the best solution. Please remember that most of this information was gleaned from trial and error, and I won't guarentee that it'll work for everybody...it works on my copies of PC-DOS 3.10 and 3.30, has not been tested on 2.xx or 3.20 or 4.xx or under the MicroSoft versions...only PC-DOS. If anybody knows any cases where it will NOT work, or whether 3.20 works more like 3.10 or 3.30, please let me know... I've worked out several routines that makes working with batch files much more acceptable, and I'd like to try and make them work on all versions...right now, I'll only guarentee PC-DOS 3.10 and 3.30. If there's any interest, I'll post the routines, and the common code that reads, modifies and writes a parent's environment. Lance -- +-------------------------+ +-----------------------------------------------+ | Lance T Franklin | | I never said that! It must be some kind of a | | ltf@killer.DALLAS.TX.US | | forgery...I gotta change that password again. | +-------------------------+ +-----------------------------------------------+