delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1999/01/03/20:27:26

From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: binary incompat TODO [Re: Strange behaviour with latest snapshot]
3 Jan 1999 20:27:26 -0800 :
Message-ID: <199901040422.WAA01772.cygnus.cygwin32.developers@modi.xraylith.wisc.edu>
References: <19990103200019 DOT A8157 AT cygnus DOT com>
To: Christopher Faylor <cgf AT cygnus DOT com>
Cc: cygwin32-developers AT cygnus DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019