This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IP_MULTICAST_IF et. all / Winsock[2] value conflict


On Sep 30 10:07, Brian Ford wrote:
> On Fri, 30 Sep 2005, Corinna Vinschen wrote:
> > On Sep 29 12:04, Brian Ford wrote:
> > > On Thu, 29 Sep 2005, Corinna Vinschen wrote:
> > > > There's no easy fix right now.  We have to drop all traces of Winsock1
> > > > in Cygwin and change the headers accordingly.
> > >
> > > Can't we just translate these based on a flag indicating what version we
> > > dynamically loaded?
> >
> > Yes, in theory we can.  But that's hell.  The definitions in socket.h
> > wouldn't be static values anymore, they would have to be translated
> > into function calls to retrieve the right value at runtime.  That's
> > bound to break building applications which rely on getting constant
> > values.
> 
> That wasn't what I was suggesting.
> 
> We can simply translate the current constant Winsock 1 values to Winsock 2
> ones when necessary in cygwin_[set|get]sockopt.  There are only 8 values
> that need changing, I think.

Yeah, I think that we can basically do something like this.  But we
should not try to guess what the application really meant to do
based on the incoming value and the winsock version in use.

Actually we have two states, applications built before we changed the
header file and applications built after we changed the header file.
This is visible by an internal version number maintained by Cygwin.
The problem is that the value can be simply wrong today, because the
application is built against the old (wrong) header file, but running
under a Cygwin which is run-time loading Winsock2.  Anyway, the idea
to convert the incoming values based on some internal information is
a good one.

> Is winsock2_active the correct flag to indicate this case?
> 
> > Really, dropping Winsock1 entirely is the way to go.  Winsock2 is
> > available since Win98 and even for Win95, there's a Winsock2 available
> > for free on some Microsoft web page (should be in the Cygwin mailing
> > list archives somewhere).
> 
> If this is really the consensus, then ok.  But, how do we maintain
> backward compatibility for previously compiled apps then?  Isn't that
> still a goal?

We can do this as I described above.  I want to drop Winsock1 support
nevertheless.  It only complicates the code and has no real gain.

> > So that's the next step to do in the networking code and, Brian,
> > while we're at it, some team work wouldn't hurt here.  I recall
> > that you have a copyright assignment in place.
> > http://cygwin.com/acronyms/#PTC
> > http://cygwin.com/acronyms/#SHTDI
> 
> I don't mind doing it once I have enough of an understanding about how it
> should be done.  That was my original road block.  I don't like wasting
> time on approaches that will never be accepted on principal.  I like
> the concept first, code later approach.

Yup, that's something for 1.5.20 or, more likely 1.5.21.  We can discuss
implementation details on cygwin-developers.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]