strange crashes on invocation

[Corinna Vinschen]

On Sep 24 10:07, Christopher Faylor wrote:
> On Fri, Sep 24, 2010 at 12:48:50PM +0200, Corinna Vinschen wrote:
> >What I'd like to propose is to minimize autoloading to the entry points
> >which are not available on all OSes.  Other than that, we should link
> >cygwin against all used system DLLs so it can profit from the fixed
> >DLL addresses and the potential speed advantage the DLL sharing grants.
> 
> I don't see how fork enters into this since Cygwin doesn't have any
> visibility into the data in a system dll.  It shouldn't matter where one
> of these guys is loaded.

Yes, in theory.  I was just thinking that this somehow looks like a
situation which appears to be similar to what happens in fork if a DLL
can't be loaded at the right spot.  I can't imagine why loading
ws2_32.dll works most of the time but sometimes fails for no apparent
reason.  Of course there are still three possible other solutions:

  - Bug in ws2_32.dll
  - Bug in cygwin1.dll
  - Bug in application

> But, coincidentally enough, I was thinking the
> same thing about dropping the dynamic linking.  It is less important now
> that we no longer support Windows 9x.
> 
> The other motivation for the autoload stuff was supposed to be reducing
> the runtime link cost of resolving symbols that would never be used.  It
> would be interesting to see if there is any noticeable performance change.
> I could see it either getting faster or slower.

I'll do some speed comparisions over the weekend.

> >Btw., I think we should also drop support for NT up to SP3.  Nobody
> >with a sane mind would run NT4 without SP6a, but SP4 is the first
> >version which made NT4 usable anyway.
> 
> Agree.

Cool.  We can finally remove the wincap.has_ip_helper_lib check and the
get_nt_ifs() function.  That's really old crap.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat