[MPlayer-dev-eng] latest mingw network patch

[Joey Parrish]

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.

Thanks for your insights,
--Joey