Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
From:	Chris Faylor <cgf AT cygnus DOT com>
Date:	Fri, 13 Oct 2000 20:49:48 -0400
To:	cygwin AT sources DOT redhat DOT com
Subject:	Re: RFC: linux compatibility
Message-ID:	<20001013204948.C3048@cygnus.com>
Reply-To:	cygwin AT sources DOT redhat DOT com
Mail-Followup-To:	cygwin AT sources DOT redhat DOT com
References:	<80575AFA5F0DD31197CE00805F650D7602CDD0 AT wilber DOT adroit DOT com>
Mime-Version:	1.0
User-Agent:	Mutt/1.3.6i
In-Reply-To:	<80575AFA5F0DD31197CE00805F650D7602CDD0@wilber.adroit.com>; from drobinow@dayton.adroit.com on Fri, Oct 13, 2000 at 06:03:56PM -0400

On Fri, Oct 13, 2000 at 06:03:56PM -0400, Robinow, David wrote:
>> > My biggest concern is backwards compatibility.
>> > Is it worth Linux compatibility if it means "cygwin2.dll"?
>> 
>> The timezone API is the biggest problem here, and the most visible.
>> Changing that might break compatibility all by itself.  I haven't
>> checked into the whole story enough to know for sure.  I agree
>> backward compatibility is an important goal.
> I'm not sure "cygwin2.dll" would be such a horrible idea.
> At the cost of a little disk space you could support two versions
>without the "you've got two copies of cygwin1.dll" problem.
> Think of all the posters to this list who've said something like
>
> " I installed the latest cygwin release and it broke <name of
>critical system here>.  I've been tearing my hair out for 3 days.
>Finally I went back to old faithful B18.  [You guys suck!]"
>
> These people could simply keep a cygwin1.dll around to run
>critical apps while at their leisure fixing whatever config
>problems they have.

The only problem with this is that we would have to worry about
interoperability between cygwin2.dll and cygwin1.dll.  This could
be a big deal.

Hmm.  Some OS's have a "personality" model.  We could actually adopt
something like that.  New code could default to the "linux personality"
while older code could stil use the default "cygwin hodge-podge personality".
This might not be feasible with some things like timezone, etc.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -