[MPlayer-cvslog] r34211 - trunk/gui/win32/interface.c

[Ingo Brückl]

Reimar Döffinger wrote on Tue, 18 Oct 2011 17:56:37 +0200:

> On Mon, Oct 17, 2011 at 12:48:20PM +0200, ib wrote:
>>
>> Try to explain why a filename conversion makes sense in the Wine port.
>>
>> -    filename = unix_name(filename);    // passed file arguments may be in Windows format
>> +    // if filename is in Windows format, convert it
>> +    // so that MPlayer will find it in the Linux filesystem
>> +    filename = unix_name(filename);

> If someone thinks "why would we need that, users can just use proper
> linux paths?" they will still be tempted to remove that code after
> reading this comment.
> As far as I can tell by what you said, the GUI file selection will
> break completely without workaround possible without this.
> If so this absolutely needs to be documented somewhere, this is
> non-obvious and critical to understanding the purpose of this code!

With this discussion I'm having a hard time to understand whether you want
me to get rid of the code or only to give a better explanation why this code
is necessary and/or to place the explanation elsewhere.

If it's just the explanation, here is another approach. If I'm wrong, please
tell me what you are expecting.

> (It also raises the question whether it wouldn't be simpler and
> more reliable to have this in the GUI code,

By "GUI code" you mean...? The X11/GTK GUI? It's in the Win32 GUI code where
it belongs IMO.

> after all you could have a file named "c:\test.avi" in Linux.

There is a bug in playtreeparser.c which prevents this currently from being
played. With a patch (see other posting), this is no problem in Linux.

The Wine port would consider this an absolute path, doesn't find it in the
C: drive mapping and refuses it. (Due to the backslash there is no way to
access it.)

> A secondary question is why MPlayer compiled for Wine will not use Wine's
> implementation of open() which would handle this correctly.

This is a good question. Maybe a native glibc C library vs. the msvcrt C
library issue. Wine produces ELF objects rather than PE32 executables and
we unset all WIN32 defines, so it's closer to Linux (which is the advantage
of this port, because all Linux stuff can be used).

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32.interface.patch
Type: text/x-diff
Size: 797 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20111019/9a650473/attachment.bin>