Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
2016-07-01 17:41 GMT+03:00 Mike Gelfand :
>
> Since you already have "bool SystemTools::GetEnv(const char* key,
> std::string& result)", another option would be to use it everywhere and
> maybe introduce something like "bool SystemTools::HasEnv(const char*
> key)" for those several cases where you only need to check the existence.
>
>
I implemented this, it's actually really nice API to work with.
2016-07-02 1:54 GMT+03:00 :
>
> ...
>
> > +#if defined(_WIN32)
> > + // Kinda hack, with MSVC (and MinGW) for some reason std::wcout
> > + // (and all other std::w*) fails once it encounters non-ASCII
> > + // string unless locale is set.
> > + // Note that even with this, seems it can't output characters
> > + // which aren't present in ANSI codepage no matter what encoding
> > + // is used for console.
> > + // Also once any character outside of ANSI codepage is tried to
> > + // be outputed then after there anymore won't be output from
> > + // any of std::w* functions.
> > + _wsetlocale(LC_ALL, L"");
> > +#endif
>
> The _wsetlocale() may be a problem.
>
> See:
> https://gitlab.kitware.com/cmake/cmake/commit/87be2e142
> https://cmake.org/Bug/view.php?id=16099
>
>
>
Indeed, good catch, thanks, I didn't thought about this. But even now
most these locale aware functions like tolower/toupper and others are
wrong because internally we use UTF-8 and there 1 character can take
more than 1 byte so these functions won't work correctly for some strings
even if we don't set any locale.
Now here we actually set it only on Windows because there just isn't any
other way. Without setting locale we get only ASCII support and can't
output even ANSI characters. With locale we can atleast output ANSI
characters.
Currently Microsoft C++ library doesn't support UTF-8/UTF-16 locales.
Only way to output Unicode would be implement our own std::wcout which
would use wide WinAPI to write to console.
Anyway quick fix is to always use English locale then number parsing
will be expected and set user's codepage.
std::wstring locale = L"English_United States.";
locale += std::to_wstring(GetACP());
_wsetlocale(LC_ALL, locale.c_str());
Of course proper Unicode support will be needed some day, but for now
this is still an improvement.
> @@ -30,8 +30,23 @@ namespace @KWSYS_NAMESPACE@
> > typedef std::basic_filebuf my_base_type;
> > basic_filebuf *open(char const *s,std::ios_base::openmode mode)
> > {
> > +std::wstring wstr = Encoding::ToWide(s);
> > +const wchar_t *ws = wstr.c_str();
> > +#if defined(_MSC_VER) && _MSC_VER >= 1400
> > +const wchar_t *ss = ws;
> > +#else
> > +const char *ss = 0;
> > +size_t length = std::wcstombs(0, ws, 0);
> > +if (length != size_t(-1)) {
> > + std::vector str(length + 1);
> > + ss = str.data();
> > + std::wcstombs((char *)ss, ws, str.size());
> > +} else {
> > + ss = s;
> > +}
> > +#endif
> > return static_cast(
> > - my_base_type::open(Encoding::ToWide(s).c_str(), mode)
> > + my_base_type::open(ss, mode)
> > );
>
> Yes. It makes sense to convert from utf-8 to code page when we are not
> using the wide apis.
> This would at least give you support for the current code page, beyond
> ascii. Beyond that, the wide functions should be used.
> Which compiler are you trying to support here, which doesn't give a wide
> open()?
>
>
Only MSVC have ofstream::open(const wchar_t *) so for MinGW need to use
ofstream::open(const char *) or use wofstream::open(const wchar_t *) which
would
require quite big changes.
> > }
> > };
> > diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
> > index 2b93e69..208e725 100644
> > --- a/Source/kwsys/ProcessWin32.c
> > +++ b/Source/kwsys/ProcessWin32.c
> > @@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s
> > /* - Data managed per call to Execute - */
> >
> > /* Buffer for data read in this pipe's thread. */
> > - char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
> > + char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2];
>
> This "*2" assumes all characters cmake sees will fit in the Basic
> Multilingual Plane.
> Are we OK assuming that?
> If the conversion from a code page to utf-16 results in surrogate pairs,
> there may not be enough space.
>
>
Not really, it assumes character string from ANSI code page encoded
to internal encoding (UTF-8) will not take more than 2x space. Which I
think is a pretty good guess, because here we're processing output
from a process and so output will be paths and texts usually in
ASCII with not many characters which would require more than 2 bytes.
And it will still work if say 1/4th uses 4 bytes and 1 byte for rest 3/4th.
1024 * 1/4 * 4 bytes + 1024 * 3/4 * 1 byte (1792) < 1024 * 2 (2048)
But of course can increase it to 4x, only I think it's very unlikely
that it will be used.
>
> >
> > /* The length of the data stored in th
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
- On Jun 30, 2016, at 8:18 PM, Dāvis Mosāns davis...@gmail.com wrote:
> On Windows getenv uses ANSI codepage so it needs to be encoded to
> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> and encode that.
>
> Also typically Windows applications (eg. MSVC compiler) use current
> console's codepage for output to pipes so we need to encode that
> to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
>
> Next, when we're outputing to console need to use wide functions.
>
> This change allows that compilers such as MSVC on Windows can be
> installed in non-ASCII path and will work correctly for all
> console's codepages which supports that path's characters.
...
> +#if defined(_WIN32)
> + // Kinda hack, with MSVC (and MinGW) for some reason std::wcout
> + // (and all other std::w*) fails once it encounters non-ASCII
> + // string unless locale is set.
> + // Note that even with this, seems it can't output characters
> + // which aren't present in ANSI codepage no matter what encoding
> + // is used for console.
> + // Also once any character outside of ANSI codepage is tried to
> + // be outputed then after there anymore won't be output from
> + // any of std::w* functions.
> + _wsetlocale(LC_ALL, L"");
> +#endif
The _wsetlocale() may be a problem.
See:
https://gitlab.kitware.com/cmake/cmake/commit/87be2e142
https://cmake.org/Bug/view.php?id=16099
> @@ -30,8 +30,23 @@ namespace @KWSYS_NAMESPACE@
> typedef std::basic_filebuf my_base_type;
> basic_filebuf *open(char const *s,std::ios_base::openmode mode)
> {
> +std::wstring wstr = Encoding::ToWide(s);
> +const wchar_t *ws = wstr.c_str();
> +#if defined(_MSC_VER) && _MSC_VER >= 1400
> +const wchar_t *ss = ws;
> +#else
> +const char *ss = 0;
> +size_t length = std::wcstombs(0, ws, 0);
> +if (length != size_t(-1)) {
> + std::vector str(length + 1);
> + ss = str.data();
> + std::wcstombs((char *)ss, ws, str.size());
> +} else {
> + ss = s;
> +}
> +#endif
> return static_cast(
> - my_base_type::open(Encoding::ToWide(s).c_str(), mode)
> + my_base_type::open(ss, mode)
> );
Yes. It makes sense to convert from utf-8 to code page when we are not using
the wide apis.
This would at least give you support for the current code page, beyond ascii.
Beyond that, the wide functions should be used.
Which compiler are you trying to support here, which doesn't give a wide open()?
> }
> };
> diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
> index 2b93e69..208e725 100644
> --- a/Source/kwsys/ProcessWin32.c
> +++ b/Source/kwsys/ProcessWin32.c
> @@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s
> /* - Data managed per call to Execute - */
>
> /* Buffer for data read in this pipe's thread. */
> - char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
> + char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2];
This "*2" assumes all characters cmake sees will fit in the Basic Multilingual
Plane.
Are we OK assuming that?
If the conversion from a code page to utf-16 results in surrogate pairs, there
may not be enough space.
>
> /* The length of the data stored in the buffer. */
> DWORD DataLength;
> @@ -1626,6 +1626,25 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess* cp,
> kwsysProcessPipeData* td)
> KWSYSPE_DEBUG((stderr, "read closed %d\n", td->Index));
> }
>
> +if (td->DataLength > 0) {
> +UINT codepage = GetConsoleCP();
> +if (!codepage) {
> +codepage = GetACP();
Can this be stored in kwsysProcessCreateInformation, and not computed ever time
we read data?
> +}
> +if (codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) {
> +int wlength = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> td->DataLength, NULL, 0);
> +wchar_t* wdata = malloc(wlength * sizeof(wchar_t));
> +int r = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> td->DataLength, wdata, wlength);
> +if (r > 0) {
> +r = WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0,
> wdata, wlength, td->DataBuffer, KWSYSPE_PIPE_BUFFER_SIZE * 2, NULL, NULL);
> +if (r > 0) {
> +td->DataLength = r;
> +}
> +}
> +free(wdata);
> +}
> +}
How about avoiding a malloc()/free() each time we read an array?
ProcessWin32.c already uses Encoding.h. How about using the Encoding instead
of
WideCharToMultiByte(...)? I'm fine either way.
Thanks for looking into this.
I had experimented with some of this as a next step, but didn't finish it.
Your general approach seems correct.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake commun
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
- On Jul 1, 2016, at 8:41 AM, Mike Gelfand mike...@mikedld.com wrote: > On 07/01/2016 05:12 PM, Ben Boeckel wrote: >> On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote: >>> 2. change GetEnv to return std::unique_ptr which will be >>> automatically deleted once out of scope and we still can check if there >>> wasn't such env if it's empty. >> Hrm. I'd rather use std::optional than relying on implicit nullptr >> semantics. > > Since you already have "bool SystemTools::GetEnv(const char* key, > std::string& result)", another option would be to use it everywhere and > maybe introduce something like "bool SystemTools::HasEnv(const char* > key)" for those several cases where you only need to check the existence. > +1 - Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
On 07/01/2016 05:12 PM, Ben Boeckel wrote: > On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote: >> 2. change GetEnv to return std::unique_ptr which will be >> automatically deleted once out of scope and we still can check if there >> wasn't such env if it's empty. > Hrm. I'd rather use std::optional than relying on implicit nullptr > semantics. Since you already have "bool SystemTools::GetEnv(const char* key, std::string& result)", another option would be to use it everywhere and maybe introduce something like "bool SystemTools::HasEnv(const char* key)" for those several cases where you only need to check the existence. Regards, Mike -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
On 07/01/2016 10:16 AM, Daniel Pfeifer wrote: >> Hrm. I'd rather use std::optional than relying on implicit nullptr >> semantics. > > +1. > > This class here should be renamed to cmOptional and moved to its own > file, so it may be reused: > http://public.kitware.com/gitweb?p=stage/cmake.git;a=blob;f=Source/cmArchiveWrite.h;h=f847d09b74922e800293e70c3171accb500c083c;hb=refs/heads/master#l22 The GetEnv method in question is in KWSys which has clients besides CMake. I'd like to avoid adding an Optional class to it or using C++11 in it. Please see my response in another part of this thread. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
On Fri, Jul 1, 2016 at 4:12 PM, Ben Boeckel wrote: > On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote: >> 2. change GetEnv to return std::unique_ptr which will be >> automatically deleted once out of scope and we still can check if there >> wasn't such env if it's empty. > > Hrm. I'd rather use std::optional than relying on implicit nullptr > semantics. +1. This class here should be renamed to cmOptional and moved to its own file, so it may be reused: http://public.kitware.com/gitweb?p=stage/cmake.git;a=blob;f=Source/cmArchiveWrite.h;h=f847d09b74922e800293e70c3171accb500c083c;hb=refs/heads/master#l22 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote: > 2. change GetEnv to return std::unique_ptr which will be > automatically deleted once out of scope and we still can check if there > wasn't such env if it's empty. Hrm. I'd rather use std::optional than relying on implicit nullptr semantics. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
2016-07-01 15:25 GMT+03:00 Daniel Pfeifer : > Hi Dāvis, > > On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns wrote: > > On Windows getenv uses ANSI codepage so it needs to be encoded to > > internally used encoding (eg. UTF-8). Here we use _wgetenv instead > > and encode that. > > Your change to the SystemTools::GetEnv function introduces memory > leaks, since you return a pointer to a new[]-ed array. > It seems impossible to refactor SystemTools::GetEnv to use _wgetenv > and provide interface compatability. > You should probably introduce a function that returns std::string and > uses GetEnvironmentVariableW internally. > > I know about memory leak, I intentionally left it this way for first version of patch as there are multiple ways how to implement it properly. POSIX's getenv doesn't need to be freed, but here for Windows since we need to encode it to internal encoding we'll be returning a new pointer. I see two ways: 1. add SystemTools::FreeEnv which delete's if on Windows but does nothing otherwise; 2. change GetEnv to return std::unique_ptr which will be automatically deleted once out of scope and we still can check if there wasn't such env if it's empty. To me 2nd option seems best. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
On 07/01/2016 08:25 AM, Daniel Pfeifer wrote: > On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns wrote: >> On Windows getenv uses ANSI codepage so it needs to be encoded to >> internally used encoding (eg. UTF-8). Here we use _wgetenv instead >> and encode that. Thanks. Clinton (in Cc) did quite a bit of work to get argv[] and file processing to use wide character APIs on Windows. It looks like environment variables are next. > Your change to the SystemTools::GetEnv function introduces memory > leaks, since you return a pointer to a new[]-ed array. > It seems impossible to refactor SystemTools::GetEnv to use _wgetenv > and provide interface compatability. We could keep our own std::map around to own the memory and use that to retain compatibility in the existing API. It would be nice to also offer an alternative API that passes ownership of the result to the caller. > You should probably introduce a function that returns std::string and > uses GetEnvironmentVariableW internally. The signature also needs to allow callers to determine whether the environment variable was set to empty or not set at all. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Improve encoding handling on Windows
Hi Dāvis, On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns wrote: > On Windows getenv uses ANSI codepage so it needs to be encoded to > internally used encoding (eg. UTF-8). Here we use _wgetenv instead > and encode that. Your change to the SystemTools::GetEnv function introduces memory leaks, since you return a pointer to a new[]-ed array. It seems impossible to refactor SystemTools::GetEnv to use _wgetenv and provide interface compatability. You should probably introduce a function that returns std::string and uses GetEnvironmentVariableW internally. > Also typically Windows applications (eg. MSVC compiler) use current > console's codepage for output to pipes so we need to encode that > to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE). > > Next, when we're outputing to console need to use wide functions. > > This change allows that compilers such as MSVC on Windows can be > installed in non-ASCII path and will work correctly for all > console's codepages which supports that path's characters. Sounds useful. I cannot really comment on this. Cheers, Daniel -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Improve encoding handling on Windows
On Windows getenv uses ANSI codepage so it needs to be encoded to
internally used encoding (eg. UTF-8). Here we use _wgetenv instead
and encode that.
Also typically Windows applications (eg. MSVC compiler) use current
console's codepage for output to pipes so we need to encode that
to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
Next, when we're outputing to console need to use wide functions.
This change allows that compilers such as MSVC on Windows can be
installed in non-ASCII path and will work correctly for all
console's codepages which supports that path's characters.
---
Source/cmBuildCommand.cxx| 4 ++--
Source/cmCommandArgumentParserHelper.cxx | 4 ++--
Source/cmExtraEclipseCDT4Generator.cxx | 2 +-
Source/cmSetCommand.cxx | 2 +-
Source/cmSystemTools.cxx | 5 +
Source/cmake.cxx | 6 +++---
Source/cmakemain.cxx | 29 ++---
Source/kwsys/CMakeLists.txt | 2 ++
Source/kwsys/Directory.cxx | 2 +-
Source/kwsys/FStream.hxx.in | 19 +--
Source/kwsys/ProcessWin32.c | 21 -
Source/kwsys/SystemInformation.cxx | 8 +---
Source/kwsys/SystemTools.cxx | 28
13 files changed, 105 insertions(+), 27 deletions(-)
diff --git a/Source/cmBuildCommand.cxx b/Source/cmBuildCommand.cxx
index fb143a2..16771cc 100644
--- a/Source/cmBuildCommand.cxx
+++ b/Source/cmBuildCommand.cxx
@@ -77,7 +77,7 @@ bool cmBuildCommand::MainSignature(std::vector
const& args)
// as the original 2-arg build_command signature:
//
if (!configuration || !*configuration) {
-configuration = getenv("CMAKE_CONFIG_TYPE");
+configuration = cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE");
}
if (!configuration || !*configuration) {
configuration = "Release";
@@ -109,7 +109,7 @@ bool
cmBuildCommand::TwoArgsSignature(std::vector const& args)
const char* cacheValue = this->Makefile->GetDefinition(define);
std::string configType = "Release";
- const char* cfg = getenv("CMAKE_CONFIG_TYPE");
+ const char* cfg = cmSystemTools::GetEnv("CMAKE_CONFIG_TYPE");
if (cfg && *cfg) {
configType = cfg;
}
diff --git a/Source/cmCommandArgumentParserHelper.cxx
b/Source/cmCommandArgumentParserHelper.cxx
index 294117c..5c615c4 100644
--- a/Source/cmCommandArgumentParserHelper.cxx
+++ b/Source/cmCommandArgumentParserHelper.cxx
@@ -71,12 +71,12 @@ char*
cmCommandArgumentParserHelper::ExpandSpecialVariable(const char* key,
return this->EmptyVariable;
}
if (strcmp(key, "ENV") == 0) {
-char* ptr = getenv(var);
+const char* ptr = cmSystemTools::GetEnv(var);
if (ptr) {
if (this->EscapeQuotes) {
return this->AddString(cmSystemTools::EscapeQuotes(ptr));
} else {
-return ptr;
+return (char *)ptr;
}
}
return this->EmptyVariable;
diff --git a/Source/cmExtraEclipseCDT4Generator.cxx
b/Source/cmExtraEclipseCDT4Generator.cxx
index 16cb082..6c9e9a1 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -208,7 +208,7 @@ void cmExtraEclipseCDT4Generator::AddEnvVar(std::ostream&
out,
// get the variables from the environment and from the cache and then
// figure out which one to use:
- const char* envVarValue = getenv(envVar);
+ const char* envVarValue = cmSystemTools::GetEnv(envVar);
std::string cacheEntryName = "CMAKE_ECLIPSE_ENVVAR_";
cacheEntryName += envVar;
diff --git a/Source/cmSetCommand.cxx b/Source/cmSetCommand.cxx
index 1484368..c0f8ab6 100644
--- a/Source/cmSetCommand.cxx
+++ b/Source/cmSetCommand.cxx
@@ -31,7 +31,7 @@ bool cmSetCommand::InitialPass(std::vector
const& args,
putEnvArg += "=";
// what is the current value if any
-const char* currValue = getenv(varName);
+const char* currValue = cmSystemTools::GetEnv(varName);
delete[] varName;
// will it be set to something, then set it
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 2d463f3..d8a1437 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -333,7 +333,12 @@ void cmSystemTools::Message(const char* m1, const char*
title)
s_MessageCallbackClientData);
return;
} else {
+#if defined(_WIN32)
+std::wstring wm1 = cmsys::Encoding::ToWide(m1);
+std::wcerr << wm1 << std::endl << std::flush;
+#else
std::cerr << m1 << std::endl << std::flush;
+#endif
}
}
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index c597605..94ecd81 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -955,8 +955,8 @@ void cmake::SetGlobalGenerator(cmGlobalGenerator* gg)
cmSystemTools::SetForceUnixPaths(this->GlobalGenerator->GetForceUnixPaths());
// Save the environment variables CXX and CC
- const char* cxx = getenv("CXX");
- const char* cc = ge
