Collabora Office on Windows crashes when opening document if installation directory has non-ASCII characters

[tml1024]

Easily reproducible when developing:

• Build the CODA solution
• Rename the windows/coda/architecture/Debug folder to something with non-ASCII characters, like "tööt"
• Start the executable from the command line or Explorer
• Before selecting a document to open, attach in Visual Studio
• Select a document to open
• Observe it crash in VS

Note that the non-ASCII characters don't even need to be ones that aren't in the so-called system codepage. But obviously when fixing this one needs to verify that it works for such, too. Even emojis.

Debugging this at the moment.

[tml1024]

And... the problem was easy to find. Already in lok_dlopen(), called from lok_init_2(), we have the line:

if (stat(install_path, &dir_st) != 0)

which obviously won't work in general. We call lok_init_2() with an install_path encoded in UTF-8. That is good. But the stat() function, like all Windows C library functions and Win32 API that take pathnames as "narrow" strings, expects the pathname to be in the system codepage.

It is important to realise here that changing the install_path to be encoded in system codepage instead, which in my case would be CP1252, is the wrong fix to this issue. That would only mean that then installation pathnames that can be expressed in the system codepage work (at least at this stage), but such with other characters still would fail. Code pages are obsolete tech and should not be used. Windows is Unicode since long and any software claiming to run on Windows should use only wide-character APIs that take and return pathnames in UTF-16.

What should be done here is to call the wide character variant of stat(), _wstat() or whatever it is called. (For stat(), the API is complicated with various versions of struct stat existing, with different types for timestamps and file sizes.)

We already have a trivial solution: lok_dlopen() should use wrap_stat() from <tools/UnixWrappers.h> here.

And next, I see that lok_loadlib() is explicitly broken, too. It uses:

return (void *) LoadLibraryA(pFN);

It should convert the parameter to UTF-16 (using string_to_wide_string() from <tools/UnixWrappers.h>) and call LoadLibraryW().

LibreOfficeKit can't have been used much in Windows apps if nobody has reported these problems before.

[tml1024]

Suggested initial change in https://gerrit.libreoffice.org/c/core/+/196401 .

But there are more problems, even if Collabora Office does not crash as such. In fontconfig, cairo, freetype.