listxml file encoding different between cmd.exe and Powershell

[darkshade9]

Hi,

Thanks for all the hard work on this project!

I was wrestling with an issue for weeks now and in communication with the creator of LEDBlinky, that LEDBlinky was unable to load clones from the file that listxml creates. He discovered it was due to a file encoding issue.

Sure enough when I checked, sending output to a file via mame64.exe -listxml > mame.xml in cmd.exe produces a ~221MB file of ANSI (listxml.xml: XML 1.0 document, ASCII text, with CRLF line terminators)
Doing the same in Powershell produces a ~442MB file of UTF-16 (pslistxml.xml: XML 1.0 document, Little-endian UTF-16 Unicode text, with CRLF line terminators)

Is this simply due to differences in sending output to a file or does mame64.exe defer to the shell you're in to determine which encoding the file gets?

[cuavas]

MAME sends UTF-8 to standard output most of the time, including for the -listxml verb. Trying to deal with anything other than ASCII on Windows is a mess. The attempts to improve the situation in imgtool seem to have actually made things worse on Windows. If you're having trouble with -listxml output, I'd recommend downloading the XML file from a release on GitHub or SourceForge.

[angelosa]

In PowerShell you can change the default stdout pipe encoding by explicitly change the UTF-16 default with this:

$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'
SO question

If you absolutely have to use the legacy CMD terminal instead it's still kinda trivial to fix instead, cfr. SU thread. If you need something more involved with CMD then at that point I'd suggest you can achieve same results with a Python script with subprocess PSL instead.

Bottom line: this sounds very wontfix league to me, pending closure unless something significant needs to be added here.

[cuavas]

Bottom line: this sounds very wontfix league to me.

It’s more “can’t practically fix unless we drop support for everything before Win10 1909”. Not sure if we really care about keeping this particular issue open.

[darkshade9]

I think the workarounds discussed here are sufficient, I don't see a good reason to spend dev cycles 'fixing' it. Perhaps a blurb in the documentation for this functionality would be enough?