windows - SetThreadLocale 到底做了什么？

Question

上周我一直在试图消除嵌入资源(通过 .rc 文件)与国际化相关的行为，这确实感觉像是某种奇怪的计算机考古学。

有关此功能的大部分信息已过时或无用，包括 official documentation .

Michael Kaplan也没有高度评价它，该博文中提供的信息似乎不再正确(即我无法重现 SetThreadLocale 具有可观察效果的任何场景)。

在相当现代的系统(例如，Win7 和更新版本)上，SetThreadLocale 实际上 做了什么，即哪些 API 受“线程区域设置”(无论应该是)？

我已经排除了任何资源加载FindResource[Ex]，包括LoadString、对话框和菜单功能； 格式信息； strsafe.h *Printf 系列； datetimeapi.h 的 GetDateFormat 等；和标准消息框。

Answer 1

我最近的调查表明，SetThreadLocale() 和 GetThreadLocale() 几乎已经过时了。至少从Win7+开始，DialogBox，FindResource等的资源LANGUAGE匹配行为不受SetThreadLocale()影响通过 GetThreadUILanguage()。

我有专门的测试程序来证明这个结论:https://github.com/chjfth/trivials/tree/master/mswin/About2-muires

SetThreadLocale 的 MSDN 页面多年来缺乏维护。一些微软员工通过打补丁而不是返工来更新它。该页面说，

SetThreadLocale affects the selection of resources with a LANGUAGE statement.

我现在几乎可以肯定它仅适用于 Windows NT4 或 Windows 95/98，非常过时的 Windows 版本，到 2022 年没有人会坚持使用。所以每个人都应该同意删除该段以避免误导。

我发现 SetThreadLocale 的唯一作用是当我们调用一些与 CP_THREAD_ACP 相关的 WinAPI 时，例如 MultiByteToWideChar(CP_THREAD_ACP, ...)，thread-locale SetThreadLocale() 设置的值将决定 MultiByteToWideChar 使用的代码页。