Thanks for the reference, but the fileutil, as is implemented, does not resolve the problem with whidechars out of machine's codepage, i.e.
- SysToUTF8 simply encode the string of chars with AnsiToUTF8, which is limited to encoding characters featured in the codepage
- find functions (i.e. FindNextUTF8) simply translate the UTF8 argument to ansi and then invoke the ansi procedure FindNext, which relies on FindNextFile (ANSI) API and write the result to the ANSI TSearchRec structure, and finally encode the result as UTF8, but af course any of those passages fails to encode characters outside codepage, replacing them with ?, char 63.
It would be needed all the functions to rely on "W" (widestring) versions of Windows API to allow handling filenames containing characters outside the machine's codepage (I know it's due to Windows which messed up things supporting two types of encoding rather than relying on something more flexible like UTF8, and don't providing a native UTF8 version of the APIs as they for widestring encoding, when they replicated all "A" APIs with a "W" counterpart).
The problem with paramstr is related to this, since it is get from Lazarus/FPC applications only in form of ANSIstring, which is not capable to keep the information about characters outside codepage (conversion fails and give char 63 as result) even if the system can correctly handle those filenames by widestring encoding.