Cannot open files when non-ASCII characters are in the path

[Nyde42]

When I try to open a file with any non-ASCII character (any codepoint >=0x80) anywhere in the pathname or filename, one of these errors shows up (using Dn-FamiTracker 0.4.0.1):

1. "This application has encountered a problem and needs to close. Unhandled exception E06D7363."
   A memory dump is generated alongside this error. This dump resulted from trying to open the file "S:\OneDrive\Music\Projects\tést\test.ftm" (notice the accent in the name of the tést folder - when I remove it the file opens just fine).
   This error occurs mostly (but not exclusively!) with characters in the Latin-1 Supplement block (codepoints <0x100). For some reason, though, the letters Žž are not part of the Latin-1 Supplement block but cause this error anyway (and there might be other characters causing this behavior, but these are the only ones I randomly stumbled across).

2. "Could not open file. <path> was not found." OR "Could not open file. <path> contains an incorrect path."
   In this case, <path> is not exactly the path of the file. Instead, it replaces all characters with a corresponding ASCII character and uses the resulting path instead. For example, if my filename is "Ā.ftm", the filename it uses will be "A.ftm". This obviously goes wrong because the file A.ftm does not exist. If it does exist, A.ftm will be opened instead of the Ā.ftm that I actually wanted.
   In cases where it cannot find a matching ASCII letter for the character, it will replace it with a question mark instead. For example, the filenames "Ɔ.ftm" and "あ.ftm" will both be replaced with "?.ftm", which results in the "contains an incorrect path" error since question marks are not allowed in windows file paths.

j0CC-FamiTracker 0.6.3 has both of these errors, too, so they definitely come from there. 0CC-FamiTracker 0.3.15.3 does not have any of these problems. FamiTracker 0.4.6, weirdly, has the second error, but it can open all files that would cause the first error in j0CC and Dn.

This leads me to believe that 0CC-FamiTracker 0.3.15.x fixed the second error, but since j0CC-FamiTracker is based on 0CC 0.3.14.5, it probably inherited the second error from there. The first error could have either been introduced in an older version of 0CC and fixed in 0.3.15.x, or it could have been introduced in j0CC.

Either way, as far as I can tell, all of this could possibly be quickly fixed by just copying & pasting a few lines of code from 0CC-FamiTracker 0.3.15.3, though I sure as hell do not feel qualified to actually do anything to this program and I don't want to break anything, so I'm hoping someone else can fix this.

[nyanpasu64]

all of this could possibly be quickly fixed by just copying & pasting a few lines of code from 0CC-FamiTracker 0.3.15.3

0CC ported the entire program from codepage-based strings to filesystem-native UTF-16 strings. I believe this is a rather involved process, and some intermediate 0CC builds would display corrupted text in some places (forgot where).

Until then, you could switch your user codepage to UTF-8, or Dn could do it itself (https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page, not sure if this will be done).