Re: GGF's extensions to GSS in Public Comment

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]