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 new functions that
receive wchar_t* (similar to WinAPI functions such as CreateFileA
and CreateFileW). I suspect that it was considered too painful...
Another way is to convert UTF-16 to UTF-8. A program receives
UTF-16 from OS, converts it to UTF-8 and calls usual libFLAC functions.
The problem here is that libFLAC interacts with the OS itself.
----------- -----------
| Program | <----------> | libFLAC |
----------- UTF-8 -----------
^ ^
| UTF-16 | ???
v v
--------------------------------------
| Windows |
--------------------------------------
So in order for libFLAC to work properly, it's necessary to add
a layer between it and OS.
------------- -----------
| Program | <----------> | libFLAC |
------------- UTF-8 -----------
^ ^ ^
| | UTF-8 | UTF-8
| v v
| ---------------------------------
| | win_utf8_io |
| ---------------------------------
| ^
| | UTF-16
v v
--------------------------------------
| Windows |
--------------------------------------
(BTW, a 'Program' here means flac.exe, metaflac.exe, or other 1st-party
.exe,
because 3rd-party programs have *NO ACCESS* to win_utf8_io).
In this case libFLAC is coupled with win_utf8_io. And even if
the program doesn't need UTF-16 support from win_utf8_io, it still
has to be linked with it.
It's possible to rearrange the latter structure into
---------------
| libFLAC |
----------- ---------------
| Program | <----------> | win_utf8_io |
----------- UTF-8 ---------------
^ ^
| | UTF-16
v v
----------------------------------------
| Windows |
----------------------------------------
so that win_utf8_io becomes essentially a part of libFLAC.
The problem here is that win_utf8_io API is *NOT A PART* of
libFLAC API. But if flac uses shared libFLAC library then
this library must export functions declared inside share/win_utf8_io.h
I don't want to say that this cannot be done: it's possible for
flac.exe to use undocumented functions from shared libFLAC library,
why not. They won't be officially available to 3rd-party apps,
only to flac/metaflac/etc.
And BTW, flac built with MSYS/MinGW-w64 (with --enable-shared option)
*DOES EXACTLY THIS*: libFLAC-8.dll exports chmod_utf8, CreateFile_utf8 at 28,
fopen_utf8, win_get_console_width, and so on, and flac.exe imports them
from libFLAC-8.dll.
So far I can see three ideal solutions of this issue:
1) Make Unicode support a part of the libFLAC API.
In this case there will be no need in separate -lFLAC -lwin_utf8_io
options, just -lFLAC will be needed.
2) Remove the dependency between libFLAC and win_utf8_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_utf8_io is a private thing that is available only to
1st-party programs. They now use libFLAC functions that take const char*
as their argument, but they can use libFLAC functions that take FILE*
or - even better - user-defined callbacks. The diagram becomes:
-------------------- FILE* or callbacks -----------
| main() | <-----------------------> | libFLAC |
-------------------- -----------
^ ^
| | UTF-8
| v
| ---------------
| | win_utf8_io |
| ---------------
| ^
| | UTF-16
v v
--------------------
| Windows |
--------------------
But it requires somebody to rewrite FLAC apps.
The third solution:
It's the simplest and requires the least amount of efforts.
In this sense, it is ideal too.
lvqcl wrote:> But it requires somebody to rewrite FLAC apps.At least I have a suggestion: to enclose all FLAC API functions that take char* filename argument into #ifndef FLAC__FILENAME_API_DISABLED ... #endif and maybe also all functions that take FILE* argument into #ifndef FLAC__FILEPTR_API_DISABLED ... #endif Then try to compile flac.exe/metaflac.exe/etc with -DFLAC__FILENAME_API_DISABLED. When it's done, remove win_utf8_io dependency from libFLAC.