https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #10 from Costas Argyris <costas.argyris at gmail dot com> --- The only interesting bit I found there was the shell script that gets called before actually running windres: https://github.com/jbruchon/jdupes/blob/master/Makefile#L201 which is doing some setup: https://github.com/jbruchon/jdupes/blob/master/tune_winres.sh It is changing some version information, but I don't think this is relevant to the problem I am having. Actually to be more precise, what I did did not fail completely, which makes this even stranger: I have a custom tool I created a while ago that you pass it the path to a Windows executable and it tells you the active code page it is using, and this tool actually reports the correct UTF-8 code page when I use the patch I posted. So it looks like it worked at first, but the arguments passed to the executable are still destroyed before main has a chance to do anything with them. It is like the executable itself is successfully converted to use UTF-8, but the setup done by the OS before reaching the entry point (main) hasn't been done properly, so the args never reach main properly. I suspect this is the part that the ms tools do that we don't. It makes some sense because on this particular problem, it is the arguments passed to the program that matter as well, not only the program itself. Perhaps the ms tools do some more work on the executable (besides just linking in the manifest) that signify to the OS loader that the args passed to it must also be interpreted as UTF-8. If such a thing is happening, our linking of the object resource file would never accomplish that I think. On another note, that program doesn't need to use the UTF-8 manifest because apparently it is using the wmain approach to get UTF-16 wide strings and converts them to char-based UTF-8, which wasn't a very good solution for gcc due to impact on the rest of the programs it spawns: https://github.com/jbruchon/jdupes/blob/master/jody_win_unicode.c
