Mailing-List:	contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive:	<http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help:	<mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender:	cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From:	Chris Faylor <cgf AT cygnus DOT com>
Date:	Fri, 23 Jun 2000 22:49:47 -0400
To:	cygwin-developers AT sourceware DOT cygnus DOT com
Subject:	Introducing slight binary incompatibility in newer executables?
Message-ID:	<20000623224947.A612@cygnus.com>
Reply-To:	cygwin-developers AT sourceware DOT cygnus DOT com
Mail-Followup-To:	cygwin-developers AT sourceware DOT cygnus DOT com
Mime-Version:	1.0
User-Agent:	Mutt/1.2i

I am contemplating a change to the cygwin crt0 code that will move some
more shared data into the DLL.  I can make the DLL backwards compatible
with older executables but making the new executables backwards
compatible with older DLLs is not as easy.  So:

DLL		"New" exe	"Old" exe
<1.1.3		doesn't work	works
>1.1.3		works		works

What's the consensus on this?  We've discussed breaking binary
compatibility from time to time.  This is not precisely that bad
but it may generate some confused mailing list traffic.

The error will be something like "entry point cygwin_user_data not
found".  The solution will be simple: "Upgrade your DLL".

The benefits are smaller user programs and a slightly faster cygwin DLL.

cgf

- Raw text -