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

[Martin Storsjö]

On Thu, 23 Jul 2009, Ramiro Polla wrote:

> Oh well, applied then...

Great, thanks!

> Thanks. And could you please test the Windows UTF-8 patch for WinCE? I
> think there might be some issues with #ifdefs and IIRC there's
> something different about the WinCE command line regarding Unicode
> (although I haven't rechecked what that is).

I tested this and found out that it's actually way more complicated than 
than I thought. I'll try to list all the major issues I ran in to:

- The non-unicode version of GetVersionEx is broken on WinCE (both 
  mingw32ce and MSVC). As for all functions handling strings, they're 
  mapped to symbol names with *A or *W depending on the UNICODE macro. 
  Even though both mingw32ce's and MSVC's headers map this to 
  GetVersionExA, there's no symbol with that name in the libs, they're 
  named GetVersionExW and GetVersionEx without any suffix. Anyway, either 
  this can be changed to use GetVersionExW and OSVERSIONINFOW explicitly, 
  or it could be skipped completely for __MINGW32CE__, since the check 
  isn't relevant for CE anyway.

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

- If using the entry point WinMain, __argc/__argv aren't initialized and 
  can't be used. Additionally, since they're referenced, they pull in 
  winmain_ce.o from libmingw32.a, so we get a double definition of 
  WinMain. (This same issue is discussed at 
  http://www.mail-archive.com/cegcc-devel at lists.sourceforge.net/msg00744.html, 
  btw.)

- mingw32ce doesn't contain any implementation of _wopen. This should be 
  simple enough to add there, though. (For testing, so I wouldn't have to 
  rebuild the compiler toolchain, I added a local implementation inside of 
  os_support.c (based on the implementation of _open from mingw32ce), 
  attached for reference.)

- The real killer issue: WinCE has no concept of environment variables 
  whatsoever. To fix builds, I've used dummy defines of getenv returning 
  NULL and setenv doing nothing, but this makes things go wrong in this 
  case. WinMain sets the FF_WINUTF8 variable to notify ff_winutf8_open 
  that file names are in utf8, but ff_winutf8_open won't know about it.  
  One potential solution would be to either hardwire it to always be in 
  use on WinCE, another is to add a local implementation of getenv/setenv 
  that stores the variables locally within the process (even though one 
  couldn't affect them with the environment where the process is started).  
  For example SDL uses some environment variables in this way, and has an 
  implementation of their own for this kind of platforms. But that API 
  would have to be exposed in order for a user of libavformat to be able 
  to change this, which was the whole point afaik.

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commandlinetoargvw.patch
Type: text/x-diff
Size: 2856 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090724/809ea957/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wopen-mingw32ce.patch
Type: text/x-diff
Size: 2433 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090724/809ea957/attachment-0001.patch>