Log Encoding Issue..

[easyatm]

The source files in WindHawk are set to UTF-8 by default. Using Wh_Log(L"中文_1"); will result in garbled output.

It is suspected that the WindHawk log window output only recognizes UTF-8, and the lack of re-encoding when reading the logs is causing the issue.

[m417z]

I improved DbgViewMini to output UTF-8-encoded text, which should improve Unicode support. Since Windhawk uses OutputDebugString for logging, which uses an ANSI buffer internally, Unicode still won't be fully supported, but ANSI characters from the system codepage should be supported. That's also how other logging tools behave, for example Microsoft's DebugView and DebugView++. Process file names, on the other hand (e.g. 中文🙂.exe), should have full Unicode support.

The new version of DbgViewMini will be included in the next Windhawk update. If you want to try it right now, you can download the latest version and replace C:\Program Files\Windhawk\UI\resources\app\extensions\windhawk\files\DbgViewMini.exe with it. You can use either DbgViewMini32.exe or DbgViewMini64.exe. Windhawk bundles DbgViewMini32.exe, but both should work in a modern OS.

[easyatm]

Thank you very much, the issue has been resolved.

Additionally, could you add a version of Wh_LogA? The OutputDebugString is also in ANSI, which would avoid the need for repeated conversions. I prefer using the ANSI version, as it eliminates the need to add L"" when using string literals.

when using "save with encoding" in the bottom right corner of the source code editor to save in a different encoding, non-English characters become completely garbled when reopening the source code. Even using "reopen with encoding" still results in garbled text.(If a Wh_LogA version can be added, hope will resolve this issue.)

I previously found that I could use DebugView to view Chinese characters. However, as long as Windhawk has opened the log window, after closing it, DbgViewMini still remains active. This competes for resources with DebugView, causing both to output incomplete logs. DbgViewMini only closes when "Exit Editing Mode" is selected.

[m417z]

The OutputDebugString is also in ANSI, which would avoid the need for repeated conversions.

I don't think it's something to worry about. The conversion is only done when logging is enabled, and it's most certainly not the slowest part of the logging process, so it's not that important.

it eliminates the need to add L"" when using string literals

Wh_Log(L"log");
Wh_LogA("log");

You exchange L with an A, doesn't seem like a huge improvement to me. Also, most WinAPI strings are wide strings anyway, so having the log a wide string is more consistent.

when using "save with encoding" in the bottom right corner [...]

That's not really supported, and I see no reason to use anything other than UTF-8 for the source code.

If a Wh_LogA version can be added, hope will resolve this issue

I think it will only make things worse. Currently you can use UTF-8 source code and do Wh_Log(L"中文🙂"); or whatever, the characters that can be represented in the system encoding will go through.

as long as Windhawk has opened the log window, after closing it, DbgViewMini still remains active

Right, I believe that using various debug log tools simultaneously is not that common, and it's more expected to have the logging continue even when the view is hidden. If you really need, you can just terminate DbgViewMini.exe.

[easyatm]

Alright, then it can only be like this. The encoding issues on Windows are indeed troublesome