dMZX Forums: MZX is completely unusable when run from a unicode path -> MegaZeux Bugs -> Tracker

MZX doesn't work well when it encounters a path with unicode characters. The required assets seem to stat fine (probably because stat() is fine with relative paths while in a unicode directory) but a variety of issues occur after mzx_res_init:

1) GLSL shaders will fail to load, leaving an unusable white screen (this produces command line warnings).
2) If not using the GLSL renderer, instead the user will see a screen consisting of only background colors because MZX silently failed to load the UI character set. This is obviously also unusable.
3) The updater fails to initialize.
4) Possibly literally anything else that relies on fopen() fails.

Ideally, MZX should be able to handle UTF paths always for any supported platform that can use them. This obviously will require quite a lot of work to fix.

Updating status to: Confirmed

This breaks moderately less bad with some characters vs. others, but can be replicated with both ã and ć in path names.

The Windows Unicode compatibility layer for these functions was implemented in GIT 1f6230f4. Currently the only live code using this is the mzx_dir functions, so behavior is still likely unpredictable. Like this issue, this needs much of the stdio file access to be abstracted to be fixed.

There's also the matter of Unicode chars displaying as garbage in MZX, but that's for a different issue/feature request.

As of GIT 649377d4 this is fixed in most places where it's relevant. The current exceptions are stdio redirect (not really intended for Windows), the help file and image utilities (common usage doesn't involve UTF paths), and screenshot features (should only be used with relative paths in the format "screen#.(png|bmp)"). Out of these, the only one that really needs to be addressed is screenshots (for platforms without chdir/getcwd).

Updating status to: Fixed
Issue fixed in: 2.93

Fixed for screenshots in GIT e8bb8dd6.