<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi All,</div><div><br></div><div>I've started some work towards supporting Unicode in CMake so I could get better support for building/testing our internationalized applications.</div><div><span style="font-size: 12pt; "><a href="https://github.com/clintonstimpson/CMake/commit/f08ca2ff65f434b2bc404000765a836880f78f0e">https://github.com/clintonstimpson/CMake/commit/f08ca2ff65f434b2bc404000765a836880f78f0e</a></span></div><div><span style="font-size: 12pt; "><br></span></div><div><font size="3">It keeps char* / std::string throughout the code where utf-8 is assumed on Windows and the current encoding on other platforms (usually utf-8). Conversions to wchar_t are done on demand when calling Windows apis. In other words, its mainly just a change to move towards unicode aware apis on Windows. It calls the wide version of Windows apis </font>explicitly, so it does not matter whether one is compiling with <font size="3">-DUNICODE/-D_UNICODE or not. I assumed Win9x support is no longer needed, so there was no attempt to enable calling the old ANSI version of the apis.</font></div><div><span style="font-size: 12pt; "><br></span></div><div><font size="3">I haven't gotten as far as I hoped because of unicode limitations in Visual Studio. For example, custom commands in visual studio executed with cmd.exe has problems with encoding. When I reported this to Microsoft, they said it works better on Windows 8, but I don't have that right now. I was able to make my own utf-8 .bat files and call cmd.exe (with </font>appropriate<font size="3"> settings) myself and it worked just fine. Somehow, its different when Visual Studio does the same for custom commands.</font></div><div><span style="font-size: 12pt; "><br></span></div><div><span style="font-size: 12pt; ">Any feedback or patches would be appreciated. For instance, std::ifstream/std::</span>ofstream/fopen need to be done special, and maybe some of you would prefer to have a wrapper for that.</div><div><br></div><div>There are plenty of changes in KWSys so the patch probably needs to be split up.</div><div><br></div><div>Although probably not an entire solution, it gets us part of the way there. I think this scope of changes can be merged in and further work done later which can include others. Overall, these changes don't really change the programs behavior except that some things which have already been working on other platforms start to work on Windows.</div><div><br></div><div>Clint</div></div></body></html>