[flac-dev] Answering the Hydrogen Audio thread
honeycomb77 at gmail.com
Tue Mar 5 17:14:46 PST 2013
(2013/03/06 6:20), Ben Allison wrote:
> My worry is more around metadata handling and parsing commandline input.
> You can't pass UTF-8 in setlocale on windows (from the docs: "If you
> provide a code page like UTF-7 or UTF-8, setlocale will fail, returning
> NULL."). There is a good chance that the behavior will still be correct
> with UTF-8 strings even when in the "C" locale, but I'm not entirely sure.
MSVC locale implementation doesn't support UTF-8.
However, it's just that you cannot use standard C wchar conversion
function such as mbcrtowc(), fgetwc(), fwprintf() or something.
You could still use WideCharToMultiByte() or something directly and it's
> If so, you might be correct, we could just add _wmain(), have it convert
> the commandline parameters to UTF-8 and call the existing main() function.
_wmain() is poorly (or not) supported by MinGW.
Instead, you can use CommandLineToArgvW(), or __wgetmainargs().
> Having proper display from the commandline is another issue entirely (and
> a painful one at that). I have some helper code for console printf that
> converts as necessary on Windows - but it's glitchy when combined with
> printf calls from elsewhere in the code due to buffering.
I think stdio buffering is not an issue as long as single thread is
You could just fflush() before WriteConsoleW() in your printf() wrapper,
and it would be enough if synchronization for multithreading is not
Actually I also have written such kind of wrapper for fdkaac frontend:
IIRC opustool just sets UTF-8 codepage(65001) via SetConsoleCP() and
directly printf'ing to console with UTF8 string.
It works, but it's also glitchy. Since console fonts are bound to each
console codepage, console window instantly gets resized when I execute
This behavior might not be visible for users using Unicode font by
default (Lucida Console or something).
More information about the flac-dev