[FFmpeg-devel] Win UTF8 patch vs WinCE (Was Re: [PATCH] Check for the isatty function)
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?
More information about the ffmpeg-devel