This is the mail archive of the
mailing list for the Cygwin project.
Re: Why does windows have such probs with dynamically loaded libs?
- From: Linda Walsh <cygwin at tlinx dot org>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Tue, 31 May 2011 17:42:11 -0700
- Subject: Re: Why does windows have such probs with dynamically loaded libs?
- References: <loom.20110529T133128firstname.lastname@example.org> <20110529233841.GC5283@ednor.casa.cgf.cx> <loom.20110530T093057email@example.com> <20110530174649.GB14225@ednor.casa.cgf.cx> <4DE5773D.firstname.lastname@example.org> <4DE579AC.email@example.com>
Eric Blake wrote:
" By loading the same dlls in the child as in the parent,
and _hoping_ that windows loads them at the same address as the parent."
Ah-hah!...that's the main rub. I could see that other pages would have
to be copied 'manually', baring some kernel call (probably an undocumented
NT call) that would allow for setting up COW pages, but guessed for copy given
the thorough level of MS documentation available on such matters.
Does cygwin actually copy, or attempt to setup COW pages that are not
from static libs? If so, wouldn't that catch dynamically loaded libs?
Windows doesn't support COW pages between a parent process and its
spawned child, at least not in the windows subsystem. And the
documentation of the various subsystems lacking to the point that cygwin
has no way of reproducing the subsystem setup utilized by Interix for
its fork implementation (Interix doesn't have to care about interaction
with the windows subsystem).
Hmmm...I wonder...do you know if Interix setups COW pages on fork?
If so, why in the heck would it perform so much more slowly than cygwin
when running the same tasks (shell scripts and such that do lots of little
forks).... its performance was pretty bad next to cygwin, though that was
under XP, and several years back that I tested, so it may have changed).
So yes, cygwin really is stuck with
copying data, and for the data not directly manageable by user space,
cygwin has to go to great lengths to circumvent random behaviors
introduced by newer windows versions to try to get dlls loaded into the
Ahhh...the 'security enhancements!'....famous for making everyone's
life more difficult...(the major failing of security design -- if it was
designed to be 'easier', everyone would use it!)
This may be complete insanity, but given the low level of support of MS's
own Unix subsystem, I wonder if they might be persuaded (if it was
desired) to lend more help or hooks for cygwin to do its magic reliably.
Put yourself in Microsoft's shoes - why would you want to make it easier
for free software
Um note, that may be 'free software', but it is running on top of
MS's paid OS. With sufficiently well developed interoperability, I could see
MS using cygwin's compat on Windows as a protective force against people
switching to linux-desktops, since with good cygwin support, they can
have the best of both worlds -- of course there's the possibility
that 'Wine' will continue to make marked improvements which could
swing things more in the linux direction.
But even there, MS could still benefit, in that the often
demanded apps run by Wine are MS apps.
Once you answer
that question, then you can see why it is unlikely that Cygwin will ever
have enough weight to convince MS to make our lives easier.
Maybe MS will try to compete with Google on 'don't be evil'? ;-)
Hey, 'it' **could** freeze over....
The real problem is the 'false lure' of corrupt business models like that
used by the record companies -- I'm sure SW companies would love to be able
to keep selling the same SW and getting royalties for life+50 (or whatever
it is these days)... Who knows -- as the government gets more corrupt and
bought out by the corps, this may come to pass...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple