[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: does setlocale work fine in Win32?

From: Leonardo Kausilas
Subject: Re: does setlocale work fine in Win32?
Date: Thu, 26 Feb 2004 15:49:28 -0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1

        I'm working with GetText on Windows and I'm needing to do a call to
"setlocale" from my main program in order to set the locale from where the
messages' catalog is loaded. ...
        What is the correct way to set the locale from inside the
application in Windows?

For applications that are ported from/to Unix, the correct way is

   if (my_setenv ("LC_ALL", "address@hidden"))

where my_setenv is defined roughly like this:

int my_setenv (const char * name, const char * value) {
[...] }

For Woe32-only applications this should work as well:

   if (!SetThreadLocale (...))

Thanks Bruno for your answer, but I still have the problem.
 My application is Windows only and I do this:

int my_setenv(const char * name, const char * value) {
        if (!SetEnvironmentVariableA(name, value))
                return -1;
        char * Buf = (char*)malloc(strlen(name)+1+strlen(value)+1);
        if (!Buf)
                return -1;
        strcpy(Buf, name);
        strcat(Buf, "=");
        strcat(Buf, value);
        if (putenv(Buf) != 0) {
                return -1;
        return 0;

I can't call SetThreadLocale becase I need to specify various different
variants (address@hidden).

I'm working in a C DLL that uses intl.dll (implicitely linked) and
provides other translation functions. This DLL is linked with the /MD
option, the same as intl.dll. From a VB app I call my DLL, which in turn
calls my_setenv for seting the locale. This does not work, the locale
doesn't change, but, if I set the environment variable from the OS, this
work fine. Why could this happen?

I'm trying to set the LANG
environment variable to the corresponding locale. If I do this from the Operating System, it works ok. But if I do it
from inside the executable with the "intl.dll" implicity linked it doesn't
work because it seems the a Windows DLL has its own copy of the
environment (if the DLL is loaded with LoadLibrary after setting the
environment variable, it works alright).

I don't believe that Woe32 DLLs have their own copies of "the environment".
If you want to argue on that, you need to be very convincing. You did not
even say whether you mean the getenv() visible environment or the
GetEnvironmentVariable() visible environment. Please consider
I did this: I implemented a tiny DLL with a print_env() function, which printed the environment variable passed as argument. When I link this DLL explicitely (with LoadLibrary) it works Ok ie. I read back the value I have set with my_setenv before the LoadLibrary call. When I link implicitely (the DLL added at link time to the app) I read back the original value, as if the DLL were keeping a forked version of the environment.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]