On Windows, when logged in with a non-ASCII username, every one of the three
documented APIs -- SHGetSpecialFolderPath(), SHGetFolderPath() and
SHGetKnownFolderPath() -- fails to retrieve any pathname at all. We cannot
account for the fact that the oldest of these continues to work with the
release viewer and within a Python script (though not, curiously, from a
Python interactive session). With a non-ASCII username, they consistently fail
when called from an Alex Ivy viewer build: "The filename, directory name, or
volume label syntax is incorrect."
Empirically, with a non-ASCII username, the preset APPDATA and LOCALAPPDATA
environment variables are also useless, e.g. c:\Users\??????\AppData\Roaming
where those are, yup, actual question marks.
Empirically, the VMP is able to successfully call SHGetFolderPath() to
retrieve both AppData\Roaming and AppData\Local. Therefore, we make the VMP
set the APPDATA and LOCALAPPDATA environment variables to the UTF-8 encoded
correct pathnames. Instead of calling SHGetSomethingFolderPath() at all, make
LLDir_Win32 retrieve those environment variables.
Make LLFile::mkdir() treat "directory already exists" as a success case. Every
single call fell into one of two categories: either it didn't check success at
all, or it tested specially to exempt errno == EEXIST. Migrate that test into
mkdir(); eliminate it from call sites.
Make LLDir::append() and add() convenience functions accept variadic
arguments. Replace add(add()...) constructs, as well as clumsy concatenations
of directory names and getDirDelimiter(), with simple variadic add() calls.
SHGetSpecialFolderPath() is deprecated, and empirically it appears to be
failing when the user name contains non-ASCII characters. The relevant
Microsoft documentation pages recommend calling SHGetKnownFolderPath()
instead.
Also, the SHGetSpecialFolderPath() calls had no error checking or reporting,
which is why we can only say it "appears to be" failing. Make sure that if
SHGetKnownFolderPath() fails, at least we try to tell somebody about it.
Trigraphs can cause some real special headaches. The only part that's annoying is the comment in newview/llimview.cpp where there's an unfortunate collision of a trigraph sequence with a character sequence that could be displayed by the viewer. Thankfully, it's only a comment!
andreykproductengine