The Portable App environment writes Unicode data as ANSI into the registry, which results in that KchmViewer Portable fails to open recent files having non-Latin characters in their paths.
Here is the screenshot about what happens when recent files are opened from the File menu. The word “Английский” should be instead of the unprintable characters between words "Category" and "English".
Prior to open this issue, I have contacted the author of KchmViewer, and he pointed me to the KchmViewer's code where recent files are loaded from the paths passed. This code does not depend on the encoding of a file path. This code calls Qt's API that performs well with non-Latin characters, e.g., "Английский", at least on *nix platforms.
Then, I've checked what the Windows Registry's records contain. Here is the screenshot. The bug is highlighted with the red rectangle.
The issue is in that Qt's API writes data in Unicode (according to its source code). However, the Portable App environment writes then this data in ANSI instead of Unicode into the registry. When opening a recent file, the Portable App environment passes the wrong registry data to Qt’s API, which results in the fail presented in the first screenshot.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Kchmviewer Portable's launcher is Unicode only. Kchmviewer always used to store the recent files list - along with most of its other settings - as a reg_multi_sz which gets exported in an oddball hex format instead of standard strings. We wrote custom code to handle portablization of it that's used in the launcher. That code may either no longer be working or may fail on your specific paths. I'll mark this as a bug and investigate.
Sometimes, the impossible can become possible, if you're awesome!
It seems that the same problem with Registry::Read is now rearing it's ugly head through Registry::Write.
REG_MULTI_SZ is apparently stored as Unicode in the registry, and instead of dealing with it as Unicode, Registry::Read/Write are treating it (as did we in the Custom Code we used to fix it for Registry::Read) as ANSI with a null character (which NSIS treats as a new line, hence how we wrote the old Custom Code) between each character.
With Registry::Read we were able to read it from the registry, take out the added, unnecessary characters, and write back to the registry, but as Registry::Write seems to assume the string is ANSI, and put null/newline ($\n) characters between any characters that don't already have it, which unintentionally puts them in the middle of Unicode characters, I don't see how we can work around this with Custom Code. This may have to wait till someone can fix NSIS' Registry plugin.
~3D1T0R
Did you see the subj in the NSIS's documentation? KiCHiK wrote that script to read REG_MULTI_SZ values for one rpetges's task. The script is based on calling standard Win API RegOpenKeyExA.
To read Unicode values, KiCHiK recommended using RegOpenKeyEx instead of RegOpenKeyExA etc in the script. I suppose, the corresponding Win API should provide writing in the same manner.
Thank you for finding this.
We'll need to confirm if the provided code works, and if so, make the change.
This is fixed in KchmViewer Portable 7.7 Rev 2. I had originally been waiting on a new version years ago but it looks like the app is no longer updated. While sorting through old bugs, I saw this one was still active. Sorry it fell through the cracks for a while.
Sometimes, the impossible can become possible, if you're awesome!