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

[Reimar Döffinger]

On 19 Oct 2011, at 18:51, Ingo Brückl <ib at wupperonline.de> wrote:

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

I would prefer to get rid of it, but I don't think that is a good idea as far as I understood your comments.
So I at least want a reminder to me and others as to why getting rid of it is a really bad idea.

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

Yes, win32 of course.

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

Do you mean with or also without the translation code we were discussing?
Btw. I just realised that the code probably can't figure out quite a few more cases like file://c:.., ffmpeg://file://, ffmpeg://cache://c: etc :-)

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

The more interesting question is whether we could do something about it.
I mean since the purpose is to test the Windows code, it would be better if we were closer to Windows behaviour - of course without losing the ability to use installed zlib etc. from Linux.

> 
> <win32.interface.patch>

Will have to look at it later, stupid mail program makes things difficult.