[flac-dev] Answering the Hydrogen Audio thread

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06.03.2013 01:20, Ben Allison wrote:
> On 06.03.2013 01:02, Chris Moeller wrote:
>> On Tue, 5 Mar 2013 11:39:19 -0500, Ben Allison wrote:
>>> On 05.03.2013 12:30, Erik de Castro Lopo wrote:
>>>> ktf said:
>>>>> No unicode support for Windows either.
>>>> 
>>>> Somebody that knows about windows unicode needs to work on
>>>> this and supply a patch. I'm happy to help out with guidance
>>>> and testing.
>>> I would be willing to add Windows Unicode support (and large
>>> file mode) to the flac binary tool, but frankly I'm not sure
>>> that it could be done as a single cross-platform source file.
>>> There would be a significant amount of either Windows API
>>> function calls or MSVC-specific extensions to the C library
>>> (like _wfopen).  It would quickly devolve into an #ifdef
>>> _MSC_VER mess.
>>> 
>> Take a look at how the Opus Tools package handles it. So far as
>> I remember, it requires minimal changes to the file(s)
>> containing references to the main entry point and to fopen. It
>> imports the command line arguments as wchar_t and converts them
>> to UTF-8, and has replacement functions for fopen and some text
>> output that accept UTF-8 instead of ANSI. I think it
>> automatically kicks in on definition of WIN32, or something like
>> that. Worth a look, at least as a base implementation.
>> 
> 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.").
You will have to hunt down the places where this happens, and do
something else. Linking to a good internationalization library would
help a lot.

> 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() requires support from the toolchain. AFAIK, only mingw-w64
supports wmain.

> 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.
How is it glitchy?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRNpe7AAoJEOs4Jb6SI2Cw/OAH/RMeFht0NN8CXXA1QZTz976N
4smLqobphozThnJP2zQPH+KJIDTZdY0WryROCO8s0t/j4CGBlTRZPlz2y2yYg49U
3ZPBcZTDSR/cN4toOBcknb9awa8XrGJy7xJcwOPzMbzowPtBpU72ablTG7D8mFow
PXhqXma99yLdQSC7LOcB/MAR1LgZxGmUUMsIig4wDL9rhZ5rzmvzLd/WWJow3WPT
4EKChs8ylxjhDrxTkCRNJ5N8WHMY1M39wx5dqkpyP0X61fIaCb0v8JbR10YPzpQG
ZJ3nX91N0aiJ3J8YLw7TML1x5xCf7hSr3BYmX2uk5A+/BtsoyeeJJsLhNe7JroY=
=Qt0d
-----END PGP SIGNATURE-----