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

Ramiro Polla ramiro.polla
Tue Jul 28 23:04:40 CEST 2009


On Tue, Jul 28, 2009 at 9:35 AM, Martin Storsj?<martin at martin.st> wrote:
> 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.

Ok, so like Reimar pointed out support for Unicode filenames that
can't be mapped to the native multibyte encoding will fail. It's
either that or the bunch of patches you posted...

>> 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?

I believe Windows takes care of that (they love backwards
compatibility) by using some thunking and loading the correct address
at boot if the function exists.

> But since there probably were some other problems on 9x(?),
> too, it perhaps doesn't matter at the moment?

I've been testing with Win98 now and the only issue left I could find
is in vfwcap that uses HWND_MESSAGE which doesn't exist in Win98. An
invisible window could be created for that, but it's more work for a
possibly non-existent user...



More information about the ffmpeg-devel mailing list