search for: win_utf8_io_codepage

That's how I understand how flac.exe works with unicode under Windows: There's a flag win_utf8_io_codepage that is equal either to CP_ACP or to CP_UTF8. Initially it's equal to CP_ACP. Then flac.exe/metaflac.exe call get_utf8_argv() that do some things and sets win_utf8_io_codepage to CP_UTF8 on success. This is the only way to set this flag to CP_UTF8. The programs continue to work only if get_utf...

...f8_io. In this case win_utf8_io will be linked statically to 1st-party apps, like other libraries from src/share: getopt, grabbag, ... 3) Leave it as is. The first solution: It's not feasible now, because the current Unicode API is too dangerous: it uses global variable 'win_utf8_io_codepage', so it's not thread-safe. At least, it's not foolproof thread-safe: it's not possible to use both UTF8-enabled and UTF8-disabled API from different threads, it's not safe to switch UTF-8 support in the middle of a program,... The second solution: Remember that win...

...anual editing of various projects in the FLAC solution. is this configuration supported? I ask because such configuration breaks support of non-ASCII filenames. Both flac.exe and libFLAC_dynamic.dll were staically linked to different copies of win_utf8_io_static.lib, then flac.exe sets its copy of win_utf8_io_codepage variable to CP_UTF8, and the copy of this variable inside libFLAC_dynamic.dll is always equal to CP_ACP. As a result flac sends UTF8-encoded strings to libFLAC, and libFLAC treats them as ANSI-encoded.

First, this dependency exists only on Windows. For obvious reasons such dependency cannot exist on Linux/FreeBSD/OSX/etc. Previous versions (up to 1.2.1) didn't support Unicode filenames on Windows. And then it was decided to add such support. Windows uses UTF-16, where characters have 16-bit wchar_t type. LibFLAC receives strings only via char*. So one way to add Unicode support is to add