This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mismatched dll

On Thu, Feb 02, 2006 at 09:58:17PM +0000, Eric Blake wrote:
> > 
> > OK, I understand now, thank you. So, it would be possible to start
> > another process, that has a well known protocol, that distributes the
> > communication between dll's, instead of sharing the memory explicitly?
> > 
> > I'm just curious, I know this isn't going to happen.
> Yes its possible (pretty much anything in computer science is,
> if you are willing to write the code and wait long enough).  The
> difference is that shared memory is SO much faster than a
> data-copying communication protocol that it isn't even funny.
> Have you ever run cygwin on a Win9x machine, where the entire
> shared region has to be copied into the correct location because
> Windows didn't provide a convenient way to lock addresses, vs.
> a WinNT machine, where the shared memory already lives in the
> correct location?  The timing difference on every fork() or exec()
> is staggering, and can't be blamed on processor speed alone.  And
> yet even cygwin on WinNT is slower than native Linux, because
> Windows doesn't provide the nice copy-on-write semantics of
> memory pages shared between processes on a fork(), at least
> not in a way easily used by cygwin.

OK, now I understand. It's currently the only practical way to
accomplish the task. 

Here's another question I have (sorry). Why wouldn't it be acceptable to
have to (different version) cygwin1.dll's running on a single system?
That is, 2 completely different Cygwin environments? So, all programs
that link against the same cygwin1.dll are in one Cygwin environment. If
there is another version of the cygwin1.dll, and programs link against
it, they would be in another Cygwin environment, completely independent.

You know, I'm sure this has been thought of before, but if it hasn't ...

> > I love Cygwin, so the following is not an attack against it, just
> > critism that one day could hopefully be resolved. The way Cygwin
> > currently can be distributed (as described above) is not 'packager
> > friendly'. If the user does happen to install your package (which has
> > cygwin1.dll in it) and then they install cygwin, the currently installed
> > package will no longer work.  I don't see any way to prevent this from a
> > packaging perspective.
> There's always another alternative - propose to maintain your
> package as part of the official cygwin distribution.  Then you
> just point people to, and source code distribution
> becomes's problem instead of yours.

OK, here I do have some evidence to support me when I say you are
partially wrong.
So, that is not a good alternative. 

Anyways, it's running circles around the point. I want to allow users to
run my program with out install Cygwin. In some situations, it's
possible installing Cygwin wouldn't even be allowed, where as simply
untaring a directory with an executable might be OK.

I've already installed 2 programs that I know of that use Cygwin. GNAT
and nx ( Both of these companies deliver the cygwn1.dll,
which totally borks my environment because I have Cygwin installed.
So I have the problem on both ends. I want to package my software to be
allowed in Cygwin (without borking others), and I know longer want to be
borked when I install other people's software that use Cygwin.

BTW, Cygwin is amazing, thanks for _all_ the great work. Hope I don't
come off ungrateful. I could literally quit programming if I had to work
on windows with out it. :)

Bob Rossi

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]