Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!princeton!rocksvax!martyl
From: martyl@rocksvax.UUCP (Marty Leisner)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Cannot putenv() in MSC 4.0
Message-ID: <1092@rocksvax.UUCP>
Date: Wed, 20-May-87 09:54:46 EDT
Article-I.D.: rocksvax.1092
Posted: Wed May 20 09:54:46 1987
Date-Received: Sat, 23-May-87 08:00:52 EDT
References: <2301@tekgvs.TEK.COM>
Reply-To: martyl@rocksvax.UUCP (Marty Leisner)
Distribution: na
Organization: Xerox: Henrietta, NY
Lines: 40
Keywords: pushd,popd,putenv,Turbo Pascal,Microsoft C V4.0

In article <2301@tekgvs.TEK.COM> toma@tekgvs.UUCP (Thomas Almy) writes:
>But putenv() does not appear to actually set the environment!  Just the one
>local to the program!  What good is this??
>
>Considering this, the example program in the Microsoft manual (which sets
>the path) is completely worthless.
>
I just spent a significant amount of time emulating putenv() for Aztec C (I
recompiled Allen Holub's shell and /util with Aztec and made some modifications --
Programs should generally only set environment variables to pass on to child 
processes.  I believe that's the way Unix works -- the child process 
inherits the environment of the parent but can't change the environment of the
parent.

MSDOS appears to do some flukey things with the environment (and I don't
think it is very well documented).  My understanding is when DOS loads a 
new program it makes a copy of the environment and the new program has a 
pointer into this space (aligned on a segment boundary).  If changes are
to be made, the environment needs to be copied into the user's data space and changes made there.

So the child program would have to take extraordinary actions to set the
parents environment (I think there's something about interrupt 2e which 
allows programs to send commands to command.com -- if this is so, doing a
SET var=name would set the parent environment (???)).  In addition, if the
child program would just clobber memory, how would it know it was overwriting
something which isn't environment space.

By the way, the environment allows me to overcome a significant limitation
of MSDOS (the 128 byte command line).  Aztec looks for a null environment
variable (an '=' with nothing in front) and will get a command line from
there if the C startup routine sees it.  So my shell automatically puts
extended command lines in the environment variable '=" before execing the
child process.  If the child was compiled by Aztec, it will get the command
line from the environment variable.


marty leisner
xerox corp.
leisner.henr@xerox.com
martyl@rocksvax.uucp