Re: GGF's extensions to GSS in Public Comment

 > Someone who thinks that environment variables are a good idea probably
 > has very little programming experience on Microsoft Windows platforms.

For implementations that aren't integrated with the Kernel, I don't
think its a question of environment variables being a good idea or
not, it's a question of "what other choice do you have?"

Ideally, I agree - it would be nice we didn't have to use environment
variables and didn't have to mess with this. But since we do, it seems
like the best idea is to expose it so that it can be handled
reasonably.

Von

Martin Rex writes (01:57 April 8, 2004):
 > 
 > Nicolas Williams wrote:
 > > 
 > > The problems with the use of environment variables are:
 > > 
 > > 1.  Environment variables are PLATFORM-SPECIFIC:
 > > 
 > >      - not all platforms can be expected to have this facility
 > 
 > Correct.  I was told that MacOS up to 9.x didn't have environment variables.
 > 
 > >      - not all platforms can be expected to have the same semantics it
 > 
 > Someone who thinks that environment variables are a good idea probably
 > has very little programming experience on Microsoft Windows platforms.
 > 
 > On Microsoft Win32 (and Win64 of course) an EXE and every single one
 > of the DLLs that are loaded by the EXE can bring along it's own
 > code instance of a C runtime library with it's own private STDC
 > objects (i.e. private FILE * handles, private heap allocators,
 > private environment variables).  And this is not only a theoretical
 > possibility, it actually happens.  It can even happen if both,
 > EXE and DLL were linked against the multi-threaded DLL "MSVCRT.DLL",
 > but built with different compiler versions (i.e. one was built with
 > Visual Studio 98 and the other with Visual Studio .NET).
 > 
 > The result is that environment variables created/updated by the EXE
 > via putenv() are not visible to the code in the DLL...
 > 
 > This is a pretty surprising (mis-)feature of the Win32 platform and
 > the result of indepedent instances of the C-Runtime library.
 > Unfortunately very few developers seem to be aware of this problem.
 > 
 > 
 > On most Unix systems this is impossible, because the commonly used "brk()"
 > interface for process heap management and this is a highlander interface
 > that cannot be used by several independent heap allocators within a
 > single process.
 > 
 > 
 > -Martin
 > 

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]