On 7/11/06, Rich Felker <dalias at aerifal.cx> wrote:
I apologize about this--I'm stuck with Windows. One possible solution that I've seen somewhere on a Cygwin/MinGW mailinglist was that I could continue passing in filenames converted to UTF-8 and then inside my ffmpeg-based program, simply convert the filenames to UTF-16. I'll be sure to send an email to the list with my results, for the sake of posterity... but I'll certainly keep in mind that MinGW just may not play well with non-ASCII text.
Ideally mingw would have a C library that treats char string filenames as UTF-8, converts them to UTF-16, and calls the native windows functions for opening UTF-16 filenames. Sadly it doesn't. I don't know what the best workaround is; even what I propose would not "play nice" with other windows apps, I fear. The core problem is that MS made a very very bad choice around 1995 and everyone is living with the effects of it now...
Rich
I was able to come up with a solution to this "Unicode" filename problem on Windows. The solution is not very far from what you had proposed above, Rich. It's actually an unimaginably simple addition to libavformat/file.c. It boils down to something like: #ifdef WIN32 static int file_wopen(URLContext *h, const char *filename, int flags) { wchar_t wPath[ strlen( filename ) + 1 ]; [ ... ] int result = MultiByteToWideChar(CP_UTF8, 0, filename, -1, wPath, sizeof(wPath)); if (!result) { return -1; } fd = _wopen(wPath, access, 0666); } #else [ file_open stuff here ] #endif Somewhat obviously the function pointer in file_protocol should be updated to use file_wopen instead of file_open, and it would be a great idea to include windows.h. :) If there's any demand for a patch or something, I'll happily oblige! At any rate, thanks for the help. Jon