[flac-dev] About libFLAC -> win_utf8_io dependency

[lvqcl]

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.