From: ericblake AT comcast DOT net (Eric Blake)
To: Bob Rossi <bob AT brasko DOT net>, cygwin AT cygwin DOT com
Subject: Re: mismatched dll
Date: Thu, 02 Feb 2006 21:58:17 +0000
Message-Id: <020220062158.387.43E28079000ACE870000018322007507440A050E040D0C079D0A@comcast.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

> 
> 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.

> > versions.  But it DOES maintain binary compatibility of the API
> > it exposes.  Cygwin releases try very hard to guarantee that
> > something compiled against an older cygwin1.dll will continue
> > to run when a newer cygwin1.dll is put in its place.  The
> 
> Yeah, that's nice. However, what happens when this changes? 

People gripe on this list.  And it usually gets fixed pretty quickly,
although you may have to rely on snapshots for a while.  And
the snapshots exist to prevent this sort of mishap on general
releases, if people would test them.

> 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 cygwin.com, and source code distribution
becomes cygwin.com's problem instead of yours.

--
Eric Blake

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/