Re: g_getenv() encoding on Windows

["J. Ali Harlow" <ali juiblex co uk>]

On 31/12/04 15:00:57, Tor Lillqvist wrote:
> J. Ali Harlow writes:
>  > I'd like to ask more about the motivation, however.
>
> (Let's restrict ourselves to NT-based Windows here, I don't really
> want to think of Win9x with its 16-bit roots...)

Sounds good. If I recall, we don't support '98 at present anyway even  
though I'd like to so we can cross that bridge if and when we come to  
it.

> The situation is quite similar as with file names, which is the main
> motivation why I suggested this. Environment variables are stored by
> the system as Unicode. (To verify, try setting environment variables
> in the Control Panel's System applet, switching keyboard layout so
> that you can enter non-system-codepage Unicode chars into the
> variable's name and/or value. The non-system-codepage chars will show
> up as question marks in the output from Command Prompt's "set"
> command, but they are correctly accessible from a program using the
> wide-char Win32 API.)
>
> To be as generic as possible and work in all circumstances, GLib
> should use the wide-character Win32 API to manipulate environment
> variables. (Just using the wide-character C runtime API is not
> enough, see below.)
>
> Another reason is that environment variables often contain path names
> directly anyway (like PATH, GTK2_RC_FILES, GTK_IM_MODULE), or are
> often used to construct file names. Thus it would be cleaner if
> g_getenv() would provide them right away in UTF-8, otherwise you
> would typically call g_locale_from_utf8() on the return value anyway.

Okay. So then, going for UTF-8 has got to be the better solution. If I  
understand what you say about MSVCRT glib can be changed to use  
GetEnvironmentVariableW() and it will still "do the right thing" even  
if the application calls putenv() since MSVCRT will call  
SetEnvironmentVariable(). But even if it doesn't I still think you're  
right and we should change it.

A slightly more interesting question occurs with g_setenv(). If we just  
call SetEnvironmentVariableW() then MSVCRT's environment will be out of  
date. This might matter if the application (or a library) calls getenv 
() or if MSVCRT itself depends on the value of the variable. If we just  
call putenv() then the system value might be corrupted if the value  
can't be represented in the system codepage. I think we're going to  
have to call both to be safe (or test if the value is representable in  
the system codepage and call putenv() or both depending).

Cheers,

Ali.