Why would Unicode Windows title-bars (only) be question mark (?) code points?

Question

There is an application from 2000. ANSI. Source is unavailable. There is a DLL in a position to hook its APIs. But even if the DLL creates a Unicode window or dialog of its own. The captions will always be literal question marks (if the code points fall outside the ANSI code page.)

It reasons there is something about the EXE image that causes this behavior. Although I am not 100% sure that I have ever tried instantiating a window with a Unicode title caption to be fair. Although I understand that it can be done.

This applies to all windows. To be sure, a window class registered with the W family of functions, and the window created with the W family and that class. I myself have never had a problem using the A and W functions explicitly. I feel like it is better style. Especially compared to wrapping string literals in preprocessor macros. Therefore I never set the Visual Studio character set regardless where it's up to me.

When creating an elaborate dialog, via DLGTEMPLATEEX (or DIALOGEX) structures the dialogs are Unicode, but only the captions are not. Any attempt to set or get the text, including InternalGetWindowText fails. It has to be something to do with the runtime versions or "manifests" or something like that (if so we can workaround this.)

There is no intermediary code involved. Indeed I am used to hooking Windows APIs. Whatever is happening it is internal. And its a real downer because custom drawing the captions is an impossibly tall order, and there are too many tool windows to leave un-captioned. We'd like for the user to be presented with real world text, not text garbage, even where the ANSI code page doesn't match.

EDITED: New information. Another application, in the same suite of programs, does not exhibit this behavior. One uses Windows, the unaffected was a fullscreen video game. Therefore this would seem to rule out the possibility of the development environment (of these programs) being a factor. It must therefore be a behavior somehow initiated by the program itself.

One thing I've recognized is IsWindowUnicode does not seem to be immutable with these programs. How can a window be Unicode, and later not. But then this could also be contextual. Although sometimes it feels more like it's permanent, usually the window will lose its Unicode status. It's just the only lead I have to go on. Perhaps there is some kind of special East Asian IME kind of system at play. I've observed a simple Edit control can start out Unicode, and then later not be. Still Spy++ reports the main Windows with the title bars are Unicode.

Also there is further information in the comments of Remy's answer. Regrettably his answer appears to be a dead end. Although a noble effort.

Including (http://forums.codeguru.com/showthread.php?419079-window-title-unicode-problem) a discussion about the same problem cropping up in what appears to be a more typical project in development.

Answer 1

Happy ending.

I noticed SetWindowsHookExA was imported. It appears that the EXE makes use of a 3rd party static library that sets up a backdoor using WH_CBT and WH_MSGFILTER hooks to basically add an additional layer to Windows that styles dialogs and probably affords the client code a way to not deal with the regular Win32 messaging framework... which can be inferred since the application basically goes dead if these hooks are cut.

I wish I could identify the product that installs these hooks. But so far I've only been able to confirm that bypassing them restores the Unicode caption functionality.

This may seem like an obscure matter. But I think there are probably others out there that would find this useful, and I'd appreciate it if the Rating for this Question would not dip lower than 0 (frankly I don't understand why 0 isn't the floor)

This is the actual solution. Although the other answer is good food for thought. Also, add SetWindowLong[Ptr] to the list of APIs that need to make use of the W variety. In truth the other APIs alluded to above don't seem to matter in this particular case, but better safe than sorry.

Answer 2

Your DLL may be creating Unicode windows, but if it is not running its own message loops to service those windows, then they are being serviced by the application's existing message loops, which are still using Ansi APIs (GetMessageA(), DispatchMessageA(), etc), so Unicode data is going to get translated to Ansi, which will lose Unicode characters that cannot be translated to Ansi. That has nothing to do with the EXE image, manifests, preprocessor, etc.