Every time when modplug is started, an error occurs about opening keybindings file (see screenshot). Probably modplug doesn't support russian letters in the path to a keybindings file, or it is some incompatibility with Win7 x64 platform.

Steps To Reproduce

Perhaps configuration of keybindings file path can help resolve this issue.

Just wanted to report this happens with dragging and dropping in midi files from Windows Explorer which have Japanese characters in the path, in version 1.22.05.00. Mildly annoying as I have to temporarily copy it to "temp.mid" or the like first. Hopefully this will be fixed at some point.

We've made some progress recently in supporting unicode filenames in as many places as possible. There are some tricky bits that will be difficult to fix (if it's possible at all), but some parts of the application can deal with unicode filenames now:

Keybinding configuration.
Drag'n'drop and loading modules from unicode paths doesn't work yet (difficult to fix) and the positions of the main toolbar and related stuff cannot be saved properly if mptrack.ini is placed in a unicode path (also difficult to fix).
If you'd like to try out the latest progress, check out http://sagagames.de/stuff/mptrack.exe

We've made more progress with regards to unicode path names during the last week. Re-download the executable from the link above to give it a try; this version can now also finally load modules from unicode paths. The autosaver is now also unicode-aware. Toolbar positions and the MRU list still cannot be saved if the .ini file resides in a unicode path, though.

Gave it a quick test and looking good - can load both .it and .mid files with Unicode characters in them. Also able to save a .it file with a filename and in a folder name with Unicode characters.

One minor flaw though is that if I have a Unicode-named file open and click Save or press Ctrl-S, instead of Save As, the Save As dialog box appears regardless - with an ASCII pathname it just immediately saves the file. It will let you overwrite the existing file though so just a minor inconvenience.

Good news: OpenMPT compiles cleanly as a Unicode application now. However, we have not tested this very extensively yet, and it's likely that it's still blowing up in some spots, so we will most likely only enable this for OpenMPT 1.28 but not for OpenMPT 1.27. Maybe we should also provide some Unicode test builds (not necessarily through buildbot just a manual build every week or so) so that users can help spotting those spots.