This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: Introducing slight binary incompatibility in newer executables?
- To: cygwin-developers at sourceware dot cygnus dot com
- Subject: Re: Introducing slight binary incompatibility in newer executables?
- From: Chris Faylor <cgf at cygnus dot com>
- Date: Fri, 23 Jun 2000 23:07:04 -0400
- References: <20000623224947.A612@cygnus.com> <200006240300.XAA13573@envy.delorie.com>
- Reply-To: cygwin-developers at sourceware dot cygnus dot com
On Fri, Jun 23, 2000 at 11:00:12PM -0400, DJ Delorie wrote:
>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?
It's data not a function. I didn't make that clear.
I could still use LoadLibrary to access it but if I did that, I think
I'd lose the benefit of the change.
I'll check for the actual error message when I finish making the changes.
I'm basically moving all of the per_process data into the DLL where,
IMO, it has always belonged.
cgf