有一个从2000年的应用程序。 来源不可用。 有一个DLL可以挂钩它的API。 但即使DLL创build一个自己的Unicode窗口或对话框。 标题将始终是字面问号（如果代码点位于ANSI代码页之外）。
原因是有一些关于导致此行为的EXE映像。 虽然我不是100％确定我曾尝试使用Unicode标题标题实例化一个窗口是公平的。 虽然我明白这是可以做到的。
这适用于所有窗口。 可以肯定的是，在W系列函数中注册的窗口类，以及由W系列和该类创build的窗口。 我自己从来没有明确地使用A和Wfunction的问题。 我觉得这是更好的风格。 特别是与在预处理器macros中包装string文字相比。 因此，我从不设置Visual Studio字符集，而不pipe它在哪里。
当通过DLGTEMPLATEEX（或DIALOGEX）结构创build详细的对话框时，对话框是Unicode的，但只有字幕不是。 任何尝试设置或获取文本，包括InternalGetWindowText失败。 它必须与运行时版本或“清单”或类似的东西（如果这样我们可以解决这个问题）。
没有涉及中介代码。 事实上，我习惯于挂钩Windows API。 无论发生什么事情都是内在的。 而且它是一个真正的低谷，因为自定义绘制标题是一个不可能的高阶，并有太多的工具窗口留下未标题。 我们希望为用户提供真实世界的文本，而不是文本垃圾，即使ANSI代码页不匹配。
编辑：新的信息。 在同一套程序中的另一个应用程序不会出现这种行为。 一个使用Windows，不受影响的是全屏video游戏。 因此，这似乎排除了（这些程序的）开发环境成为一个因素的可能性。 因此，它必须是由程序本身发起的某种行为。
我已经认识到的一件事是IsWindowUnicode似乎不是这些程序不可变的。 一个窗口怎么可能是Unicode的，后来又不是。 但是，这也可以是上下文的。 虽然有时候感觉更像是永久的，但是窗口通常会失去Unicode的地位。 这是我唯一要做的。 游戏中可能还有某种特殊的东亚IMEtypes的系统。 我已经观察到一个简单的Edit控件可以启动Unicode，然后不会。 Still Spy ++报告标题栏的主窗口是Unicode。
雷米的回答也有更多的信息。 遗憾的是，他的回答似乎是死胡同。 虽然高贵的努力。
包括（ http://forums.codeguru.com/showthread.php?419079-window-title-unicode-problem ）关于在似乎是一个更典型的发展项目出现的同样的问题的讨论。
您的DLL可能正在创建Unicode窗口，但是如果它没有运行自己的消息循环来处理这些窗口，那么它们将由应用程序的现有消息循环提供服务，该循环仍在使用Ansi API（ GetMessageA() ， DispatchMessageA() 。等等），所以Unicode数据将被转换成Ansi，这将丢失不能转换成Ansi的Unicode字符。 这与EXE图像，体现，预处理器等无关。
美好的结局。
我注意到SetWindowsHookExA被导入。 看来，EXE使用第三方静态库，使用WH_CBT和WH_MSGFILTER挂钩设置后门，基本上添加一个额外的层到Windows的样式对话框，并可能提供了一个不处理常规Win32消息框架…这可以推断，因为应用程序基本上死了，如果这些钩子被切断。
我希望我能识别安装这些钩子的产品。 但到目前为止，我只能确认绕过它们恢复Unicode字幕功能。
这可能看起来像一个晦涩的事情。 但是我认为可能有其他人会发现这个有用的，我会很感激，如果这个问题的评级不会低于0（坦率地说，我不明白为什么0不是地板）
这是实际的解决方案。 虽然其他答案是好的食物。 另外，将SetWindowLong [Ptr]添加到需要使用W变种的API列表中。 事实上，上面提到的其他API在这种情况下似乎并不重要，但是比抱歉更安全。