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 05:52:57PM -0800, Brian Dessent wrote:
> Bob Rossi wrote:
> 
> > 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.
> 
> It *is* possible to create two Cygwin DLLs that can co-exist.  But to do
> so requires much more than just naming them differently.  The source
> code must be modified to use a different filename/identifier for the
> shared memory region, as well as different registry keys for the mount
> table.  The Cygwin testsuite does a limited version of this to allow
> running the just-built Cygwin DLL for the purposes of executing the
> tests, from within the developer's existing Cygwin environment.

Nice, I was wondering how you could develop on Cygwin without this
capability. That makes perfect sense. I'm just guessing, but it might be
a good idea to make this hardcoded constants dynamic, so that any
arbitrary number of cygwin1.dll's can coexist.

> So yes, it can be done.  But it is a very bad idea to do so.  If you
> made two DLLs that were isolated in this way they would be truly
> isolated -- you could not send signals from one to the other, they would
> not see each others processes in their PID tables, and so on.  It would
> be the absolute worst way to have two sets of software interact.

OK, we are looking at things from 2 different perspectives. I want to
make it so that they can not interact at all. That would be my goal. I
want to deliver a cygwin1.dll with a program, and ensure that it will
never ever interact with the users cygwin1.dll.

> This is ESPECIALLY true when the code goes to great lengths to be
> backward compatible.  The idea is that you can ALWAYS replace an
> existing cygwin1.dll with a newer one, without recompiling the old apps
> that were linked against the old version of the DLL.  You of course
> can't go in the other direction (using an older DLL with newer .exes)
> but this backwards compatibility is in theory good all the way back to
> version 1.0.0 from circa 1998-ish.  So there is no reason why you should
> ever need two Cygwin DLLs in the first place, because you can always
> replace an older one with a newer one.

There is at least 1 single reason. There is no possible way for a
developer to package a project and deliver it, and guarantee that it
will work. Either the user has cygwin installed (possibly catchable). Or
the user doesn't have Cygwin installed, installs your package, and then
later installs Cygwin (your package just got borked).

However, I see your point about backwards compatibity. That's wonderful.

> If you are writing an installer of a third party application the basic
> logic should thus be:
> 
> Is a cygwin1.dll already on the system somewhere?
>   Yes:
>      Is it newer than mine?
>         Yes: Install my .exe, but do not install my cygwin1.dll,
>              use the existing one.
>         No:  Prompt user of the situation, and either bail or 
>              overwrite older DLL with newer DLL.
>   No:
>      Install my DLL.

OK, see my comment above please. Also, what do I do about these jerks?
that package cygwin1.dll in there projects even though I have Cygwin
installed?

Brian, thanks for the input, it's very valuable. All in all, I can live
with your suggestions above, and will figure out a way to get done what
I need done. I'm just trying to suggest that there is a good reason to
possibly do the suggestion I have in the top paragraph. I think it would
help the community a lot.

People (not developers) downloading softare want to install an
executable throng some kind of package installer, and then run an
executable. They do not want to install Cygwin, and then start a
terminal, and then start a program. This is all just my opinion.

Thanks,
Bob Rossi

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


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