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
Date:	Fri, 23 Jun 2000 23:00:12 -0400
Message-Id:	<200006240300.XAA13573@envy.delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	cygwin-developers AT sourceware DOT cygnus DOT com
In-reply-to:	<20000623224947.A612@cygnus.com> (message from Chris Faylor on
	Fri, 23 Jun 2000 22:49:47 -0400)
Subject:	Re: Introducing slight binary incompatibility in newer executables?
References:	<20000623224947 DOT A612 AT cygnus DOT com>

I don't think this is any different than any other time we've added
functionality to the dll.  Every time we export a new function, we
create the opportunity for new programs to not work with old DLLs.
Aside from bug fixing, this is how we define "progress".

I don't see a problem with your proposed change.

However, watch out for the *library* compatibility stuff.  Don't
forget the ctype disaster.

> The error will be something like "entry point cygwin_user_data not
> found".

More likely, something like "Error loading program" or "program not
found".  Windows isn't very helpful with its error messages.  Or are
you using LoadLibrary to access this new function?

- Raw text -