*A Win32 API 调用仍然相关吗？答案

【问题标题】：Are the *A Win32 API calls still relevant?*A Win32 API 调用仍然相关吗？
【发布时间】：2010-06-08 21:38:21
【问题描述】：

我仍然看到有关使用 LPTSTR/TCHAR 类型等而不是 LPWSTR/WCHAR 的建议。我相信 Unicode 的东西在 Win2k 中得到了很好的介绍，坦率地说，我不再为 Windows 98 编写代码了。（当然，特殊情况除外。）鉴于我不关心 Windows 98（或者，甚至更少，ME），因为它们是十年前的操作系统，是否有任何理由使用兼容性 TCHAR 等类型?为什么仍然建议人们使用TCHAR - 它比直接使用WCHAR 有什么好处？

【问题讨论】：

类似于stackoverflow.com/questions/234365/is-tchar-still-relevant
我没有看到开发者建议使用TCHARs。但是，我看到开发人员建议保持一致。如果你调用通用 API 版本（例如CreateFile），那么你需要保持一致并传递一个LPCTSTR。你确定你没有混淆这些吗？

标签： windows winapi

【解决方案1】：

如果有人告诉你要走多达 1,000,000 行非 _UNICODE C++ 行，并使用 char 而不是 wchar_t 或 TCHAR 或 WCHAR 进行大量声明，你最好准备好应对非 Unicode Win32 API。大规模的转换成本相当高，而且可能不是来源资金准备支付的费用。

至于新代码，嗯，有很多使用 TCHAR 的示例代码，它可能更容易剪切和粘贴，在某些情况下，WCHAR 和 wchar_t 和 WCHAR 之间存在一些摩擦unsigned short.

谁知道呢，也许有一天 MS 会在 TCHAR 下添加一个 UTF-32 数据类型？

【讨论】：

关于扩展 TCHAR 可能性的有趣点。不太可能，因为 UTF-32 可能会在几乎所有存在的实际文本上占用更多空间。 HTML5 完全拒绝它作为一种编码。
@kib UTF-32 评论是为了幽默。
@kibibu：afaik 它已经在某些平台上发生了。上次我在 g++/linux 上检查 wchar_t 是 4 个字节。
我想这个问题主要针对新代码：如果您使用 *A 的东西，那么无论如何您都完全错过了 Unicode。如果您使用 char 而不是 TCHAR 或 WCHAR，那么您又遇到了更大的问题。

【解决方案2】：

实际上，unicode 版本的函数是在 1993 年的 Windows NT 3.1 中随 Win32 引入的。事实上，在基于 NT 的 ose 上，几乎所有的 *A 函数都只是转换为 Unicode 并在内部调用 *W 版本。此外，通过Microsoft Layer for Unicode 支持 9x 上的 *W 函数。

对于新程序，我肯定会推荐直接使用 TCHAR 宏或 WCHAR。我怀疑 MS 会在 NT 的生命周期内增加对任何其他字符大小的支持。对于现有的代码库，我想这取决于支持 Unicode 的重要性与修复它的成本。 *A 函数需要永远保留在 Win32 中以实现向后兼容性。

【讨论】：