Applications are made to solve problems, just like programming languages are made to describe problems.

Over the recent months @acmilan have posted heavily on topics like Encoding, Charset, and API compatibility when dealing with anything non-ASCII.

And I did read some of those articles.

To be fair, those articles did address the problem of How to process strings in VisualSomething without fear in every possible case, but did not generally help (and will never) with the problem of How to process strings with least effort and maximum efficiency.

In order to run anything on Windows, one will certainly need to generate some system calls, that involves Win32 API. But string operations should really be separated from API calls themselves.

In the old days where UTF-8 was not famillar, having code pages are great... Just not that great today. Today we have tons of third party solutions that can handle strings of all forms properly, so it simply makes no sense to discuss heavily around that. After all, this forum is about developing applications on Windows, not avoiding traps set by the Evil Microsoft / turn the framework over to get the job done, am I right?

You are right. Maybe I am overthinking about effects on VC++ not supporting UTF-8 and broken Win32 Console NLS. The former problem might not be M$'s fault, but the English-only library's author's. Also, not so many libraries have been ported to Windows correctly, in fact, if had been, M$ would not have made the LXSS. So it does not really matter. The latter one is M$'s, but some other UIs (eg. TextBox in WinForms) or IPCs (eg. files, pipes, sockets) can replace it. As a conclusion, avoid using fxxking VC++, English-only libraries and Win32 Console ourselves, and program happier.