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@28,
fopen_utf8, win_get_console_width, and so on, and flac.exe imports them
from libFLAC-8.dll.
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
