Mail Archives: cygwin-developers/1999/01/03/20:27:26
Christopher Faylor <cgf AT cygnus DOT com> writes:
>
> It is beginning to sound like we should release a B21 very soon which breaks
> binary compatibility with older versions of cygwin. The termios changes
> were inavoidable but they may end up causing some problems.
If we're going to break binary incompatibility, we should also do a few
other things:
- change all __imp__ to _imp__ ; or, better yet, use dllimport
attribute. It actually may not break binary incompatibility, but
then again it may. It may sound to be a waste of effort, but it's
important for future possible compatibility with native compilers
and tools.
- change the DLL entry point to be something more reasonable that
_cygwin_dll_entry! Let's use MSVC compatible names. While we're
at it, let's add a different default entry point for GUI apps,
which could be the same as the console one for now. In the future,
we could then use information set in the GUI entry routine to
for example issue error messages via windows so that they don't
get lost.
- We can also now add an extra parameter to support Cygwin DLLs from
non-Cygwin apps without having to maintain two different entry
points. DJ's last patch had something like that, and so did one of
my original changes that I had sent just after b20 (but not the
final one that's in b20.1).
- Perhaps dump the dlltool's backward compatibility hack of producing
__imp__ (old style) import entries. This causes the import libraries
to be twice as large, and when you deal with import libs of 8-10M,
it does make a difference. This is low priority of course.
I'm sure I'm forgetting lots of things. I do know that we should take
the issue of breaking binary compatibility seriously and try to do as
much now so that we don't have do this in the near future. It's a
thankless job; just wait till the mailing list goes nuts complaining
about everything under the sun.
Comments?
Regards,
Mumit
- Raw text -