Re: getenv and Woe32

[Bruno Haible]

Guido Flohr wrote:
> I have a problem with the MSVC compiled version of the gettext runtime
> libraries under Windows.  I change the environment variables LANG,
> LANGUAGE etc. from within a Perl module, and Perl uses the win32
> functions SetEnvironmentVariableA/SetEnvironmentVariableW for
> manipulating the environment.  See
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setenvironmentvariable.asp
>  for a description.
>
> GNU gettext, however, uses getenv() to read the environment and never
> sees these changes.  An explanation for this can be found under
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt_getenv.2c_._wgetenv.asp
>
> It says:
>
>       getenv operates only on the data structures accessible to the
>       run-time library and not on the environment segment created
>       for the process by the operating system.

OK, so in Windows, each process has two environment blocks, one maintained
by the OS and one maintained by the C library.

> For OS2 there is a special version of
> getenv() in gettext-runtime/intl/os2compat.c which has a comment "A
> version of getenv() that works from DLLs", and I suspect that a special
> getenv() function for Windows is also needed.

In Windows 3.1 DLLs were independent from processes, and OS/2 DLLs have
a similar age. I believe that Woe32 DLLs are a little saner w.r.t. to
their interaction with processes and with global variables like _environ.
So I don't think this is the main problem now.

> I am no Windows expert and can only guess which behavior is correct for
> Windows, Perl's or GNU gettext's.

Windows clearly documents its limitations. "Here this ISO C function is
available, but it doesn't work"...

Perl can be compiled with USE_WIN32_RTL_ENV so that is calls putenv()
instead of SetEnvironmentVariable().

If you want your programs to work on Woe32 like they do on Unix,
setting an environment variable should always call both putenv()/setenv()
and SetEnvironmentVariable(); see
http://www.cygwin.com/ml/cygwin/1999-04/msg00478.html
This is often not done for performance reasons. But it could be a third
mode of operation for Perl under Windows.

I won't change libintl for this issue since none of the two environment
access methodologies is clearly right or clearly wrong. Instead, libintl
should be extended with an API that allows to specify the locale explicitly
rather than through environment variables. Until then, please build
your Perl differently, or don't use Windows :-)

Bruno