[FFmpeg-devel] Win UTF8 patch vs WinCE (Was Re: [PATCH] Check for the isatty function)

Martin Storsjö martin
Tue Jul 28 14:35:28 CEST 2009

On Tue, 28 Jul 2009, Ramiro Polla wrote:

> > That's probably the easiest way out, yes. Unicode command line parameters
> > work just fine anyway, the only difference is that users of libavformat
> > have to enter data in the native multi-byte charset, instead of utf8.
> Unicode works fine the way it is in WinCE?

If you launch ffmpeg.exe with CreateProcessW, unicode filenames in the 
arguments work just fine; mingw32ce:s main() wrapper converts the unicode 
to normal chars using wcstombs, into the native multibyte encoding. Then 
at least when opening using open() (didn't check any other codepaths), the 
same multibyte names are mapped back into unicode/wchar_t using mbstowcs 
and passed on to CreateFileW.

So this works for all unicode file names that can be encoded in the native 
multibyte encoding, whichever that happens to be.

As for users using libavformat on WinCE; they'd have to provide unicode 
filenames in the native multibyte encoding instead of in UTF8.

> Quoting Martin from another message:
> > - CommandLineToArgvW doesn't exist on WinCE (neither on mingw32ce nor on
> >  MSVC). I tried to hack together a seemingly compatible replacement, but
> >  that's 90 lines extra cruft. (Attached for reference.) I also noticed
> >  that this function isn't available on win9x, FYI.
> Hmm, it seems this function is only available if MSLU is used. So in
> the new patch I'll send in a while it'll just be plain disabled on
> Win9x. It'll be left for lavf anyways, so users may link with MSLU and
> still use Unicode in Win9x.

Won't you get an error at startup if that symbol isn't available, even if 
you don't use that codepath, or is this handled in some special way 
internally? But since there probably were some other problems on 9x(?), 
too, it perhaps doesn't matter at the moment?

// Martin

More information about the ffmpeg-devel mailing list