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.