多语言支持是个古老的问题，牵扯到各个层面上的问题，包括操作系统、字符集、程序本身的支持等等。命令行下是否能够完全支持多国语言呢，下面进行一些尝试，用来打破一些既定的错误概念。
Visual Studio默认不支持UNICODE化的代码文本与资源本文。
倘若VS做的那么完美，还要命令行的编译结构以及各种第三方辅助的开发工作作甚？VS默认情况下是和VS的语言环境绑定起来的。比如我在英文的Vista x64下使用的中文VS 2005，默认VS的区域只有两个，“中文”或者是“与Windows相同”。而且，在这个环境下新建的代码文本的编码多半是本地代码，如GBK，根本不是UNICODE，于是乎从底层支持UNICODE也无从谈起。而Linux上的文本编辑器以及Code::Blocks默认就是UTF8，可以想象，在多区域多语言合作的软件开发环境中VS的这个“特色”会有多么的麻烦。
VS的资源编辑系统支持UNICODE的显示，默认却不将字符串作为UNICODE编译进程序。
是的，你没有看错，我差一点就被这个骗过去了。
添加一个字符串，然后切换到德语输入法输入“Wörter”，其中“ö”是CP1252的字符，不是中文CP936字符。然后用LoadStringW（防止程序自己进行转换）载入到程序，打印出来肯定是
0057 003f 0072 0074 0065 0072
其中3f就是那个“?”，ASCII中的问号一枚而已，根本不是我们想要的00f6。再以代码方式打开资源文件，是不是看到这样的惨状，
开始我还以为是由于没配置好setlocal，反复测试最后发现在植入程序的时候VS就已经自作聪明的帮你转换成了问号。这算VS的一个BUG呢？还是FEA呢？
晓得了这个问题，解决方法就有了：在所有的字符串前加L转换为宽字符串。可是一旦你按Ctrl+S保存后，VS又自作聪明的去掉了L，真不是一般的愚蠢！对比了一下WxWidget，人家早就进化到了基于XML的数据文件XRC。可是这个VS的这个特色估计已经延续了许多年了，MS还是没有修复。
千万别以为.net时代了，古老的WIN32、MFC程序就不需要维护了，事实上还是有许多程序依旧不是虚拟机的，于是需要照顾更多。比如3dsmax，那个STRING_TABLE长得吓人……
Windows命令行默认使用本地字符集。假如你没有调用CHCP 1252切换到德语字符集，那么那个字符即使16进制显示是正确的，也无法打印出正确的字符。还是老老实实的先切换字符集吧，别瞎折腾了。
或者大家统统都写英文程序吧，这个最一劳永逸。