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?