[MPlayer-dev-eng] latest mingw network patch

[D Richard Felker III]

On Sun, Jun 08, 2003 at 04:29:20AM -0500, Joey Parrish wrote:
> On Sun, Jun 08, 2003 at 01:27:38AM -0400, D Richard Felker III wrote:
> > > What I'm saying is that since Cygwin is an emulation environment.  If we
> > > have a working cygwin port, then the cygwin DLL is calling certain
> > > native windows functions.  If we port to mingw, then we are calling all
> > > these things ourselves directly.  This leads to greater efficiency IMHO,
> > > and also more portable code in general by abstracting the
> > > operating-system specific things.
> > > 
> > > Since the cygwin environment can compile code that is independant of the
> > > cygwin DLL by using the mingw runtime, there's no reason to use anything
> > > else.  Native windows binaries run fine in cygwin, too.  :)
> > > 
> > > As for being like SDL, the problem with SDL lies in the fact that it is
> > > a library that tries to force -mno-cygwin on it's apps.  That is not at
> > > all the case for mplayer, so I believe that this will not be a problem.
> > > 
> > > Anyone have other thoughts?  Did I miss anything?
> > 
> > Yes. In the future mplayer might want to [optionally] have access to
> > unix-specific functionality which cygwin could provide, but which
> > would not be easy to implement in the mingw port. Also some users may
> > just prefer to have a clean all-cygwin environment, or might want to
> > use free software (cygwin's dll) rather than non-free (msvcrt).
> 
> In the future, hopefully there won't be any unix-specific functionality
> that cygwin can provide that can't be written natively.  Wouldn't you
> agree?  And I still do not see why the mingw runtime is good for mingw
> but somehow frowned upon for cygwin.  Isn't the mingw runtime what
> cygwin uses with -mno-cygwin?  Isn't this different from msvcrt?
> 
> > Whatever the reasons, there is no excuse for shutting out user choice.
> > MPlayer should build as mingw by default on mingw and as cygwin by
> > default on cygwin. If the user wants to build a mingw binary using
> > cygwin, you can have them pass --enable-mingw or something to
> > configure...
> 
> I still do not see this as a matter of shutting out choice.  At this
> moment it would be, but only because we still rely on the crutch of the
> cygwin unix emulation dll.  I still do not see how mingw code could be
> worse once it supports everything the cygwin port does.  When I talk
> about making mingw port replace cygwin port, I mean only when the cygwin
> port is obsolete.  That means everything in cygwin works in mingw, and
> the emulation layer is no longer an advantage.  This is not something
> that will happen right away, but I believe that it should be our goal.

Also consider that someone using mplayer as a part of a cygwin
environment will want it to use unix-style paths, and will be very
annoyed if it only support ms-style ones (which will be the case if
it's built mingw-only). You're viewing the whole situation from the
perspective of an ordinary windows user who wants a windows app, and
that's ok, but keep in mind that not everyone has the same
perspective. I maintain that there is NO REASON to require cygwin
users to build mplayer for a mingw target when the existing cygwin
target works perfectly fine.

Rich