The reason for this problem is that Windows doesn't like UTF-8 for filenames. chdman createdvd works because its implementation uses MAME's osd_file::open, whose Windows version uses actual Windows system calls and translates all filenames to UTF-16. Unfortunately, MAME's CD-ROM parsers mostly use fopen, which is known not to accept UTF-8 filenames on Windows.

mame could opt in to UTF-8 support with a manifest setting just as it currently does for DPI awareness and long path awareness. Currently only the main executable embeds a custom manifest, so the tools would need to be updated to do this as well.

https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#activeCodePage

mame could opt in to UTF-8 support with a manifest setting just as it currently does for DPI awareness and long path awareness. Currently only the main executable embeds a custom manifest, so the tools would need to be updated to do this as well.

https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#activeCodePage

That requires a relatively new version of Windows to work (we still support older versions of Windows), and using it breaks the code in util:core_file that’s supposed to use the user’s legacy “ANSI code page”.

That requires a relatively new version of Windows to work (we still support older versions of Windows), and using it breaks the code in util:core_file that’s supposed to use the user’s legacy “ANSI code page”.

What do you expect to break? If the user sets UTF-8 as their system-wide code page, it will have the same effect on MAME as this manifest setting (so the same things will break).

That requires a relatively new version of Windows to work (we still support older versions of Windows), and using it breaks the code in util:core_file that’s supposed to use the user’s legacy “ANSI code page”.

What do you expect to break? If the user sets UTF-8 as their system-wide code page, it will have the same effect on MAME as this manifest setting (so the same things will break).

Well if the user doesn’t set their system-wide ANSI code page to UTF-8, they shouldn’t be expecting applications to use UTF-8 for things that are nominally supposed to use the system-wide ANSI code page.

But that aside, the code doesn’t work for ANSI code pages where the are more than two possible coding lengths for characters (e.g. GB2312 and Shift-JIS work, GB18030 and UTF-8 don’t).

Well if the user doesn’t set their system-wide ANSI code page to UTF-8, they shouldn’t be expecting applications to use UTF-8 for things that are nominally supposed to use the system-wide ANSI code page.

Ah, if supporting legacy code pages is a goal then I understand why you can't override it.

But that aside, the code doesn’t work for ANSI code pages where the are more than two possible coding lengths for characters (e.g. GB2312 and Shift-JIS work, GB18030 and UTF-8 don’t).

I found the code you are referring to (in osd_uchar_from_osdchar) and yes, unfortunately that's already broken in its current state, but I see there's already a FIXME comment.

Thanks for explaining the reasoning here; guess there's no shot at a free lunch.

Similarly, chdman currently cannot create files with East Asian character file names, such as files named with Chinese, Japanese, and Korean characters.