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: Why only 1 cygwin1.dll?


On Tue, 28 Mar 2006, Bob Rossi wrote:

> Sorry for my late response. I've been busy.
>
> > What's wrong with third parties simply installing any cygwin1.dll that
> > they want to distribute (subject to the GPL of course) in a
> > setup-compatible location and way?  Then the only question is whether
> > to install over any existing DLL or not.  That's the same old issue
> > that all installers have with any shared DLL.  Using the accepted
> > practice of replacing any existing old DLL with a newer one (by
> > comparing version) should work fine.
>
> OK, I see your point here, but it only works when you have every 3rd
> party following the same rules. Does this seem possible to you? It
> doesn't to me.

Well, look at it this way: there are two kinds of 3rd parties -- 3PDs (3rd
Party Distributors), who follow the rules, and whose users receive at
least some support on this list for their Cygwin-related problems, and
3PPs (<http://cygwin.com/acronyms/#3PP>), whose users elicit only one
response on this list: "uninstall that package, and then we'll talk".
It's up to each individual 3rd party to decide which one to be.

> > Removal of shared DLLs across apps is a common problem for any Windows
> > app too.  I don't believe the Cygwin distribution and any 3rd party
> > distributor throws a new wrinkle into this.  I've seen many an
> > uninstaller ask me if I want to delete XXX.dll that could still be
> > needed by other apps. Same rules apply.  The worst case is that one
> > cygwin1.dll gets left on a user's system after all apps using it have
> > been uninstalled.  That's par for the course with Windows.  And at
> > least if the DLL is always in the setup- compatible location, it would
> > be easily found and used/overwritten by any subsequent installation,
> > 3rd party or otherwise.
>
> OK, you are correct here, however, I plan on doing something a little
> different. I'm assuming many people on this list have much more
> knowledge than I do about these subjects, but I'll attempt anyways.
>
> I would like to package an executable and put the DLL in the same
> directory as the executable. That way, I don't really care if there is a
> different version on the system, my program will always use my version.
> Also, when I uninstall the application, I simply remove the executable
> and all the DLL's. By packaging this way, I sidestep replacing DLL's and
> uninstalling issues.

But you add a whole heap of potential problems -- for example, suppose
either your installer or the user herself adds your package directory to
their PATH.  Boom -- both your package and their Cygwin installation (if
they have one) break.  Refer to the above taxonomy of 3rd party providers
for the measure of support they will receive.

> Now, as far as a tool to help users install Cygwin. I don't think this
> is a possible task, and I will explain why. Two different cygwin1.dll's
> can not be used at the same time by two process's.

True for most practical purposes.

> Therefor, each time an application starts (including Cygwin?) it must
> check to see if a cygwin1.dll is already loaded by the kernel. If it is
> loaded, then mv the distributed cygwin1.dll out of the way so that the
> executable being started uses the already loaded cygwin1.dll. If it is
> not loaded, mv the distributed cygwin1.dll so that the started
> executable will use the distributed cygwin1.dll.

Huh?  If you share the cygwin1.dll, none of this is needed.

> Each 3rd party application needs to honor this, and that includes cygwin
> itself. Does this seem possible to you? Also, this yields "the chicken
> or the egg" problem, which would force 3rd party applications to have
> the program the user starts be a bash script, which handles all the
> dirty work until it is safe to start cygwin (or use dlopen on cygwin?).

Huh?  If the 3rd party app is linked with cygwin1.dll, it'll do the "dirty
work" itself.

> Next, putting cygwin1.dll in a common place could prove to be very
> problematic.

Why?  Thousands of Cygwin users have in in the common place -- i.e., the
/bin directory off the root of their Cygwin installation.

> If it is not in the directory where the program is executed, then it
> needs to be on your path.

Yes.  That's one possible caveat (and even that can be avoided by
modifying the PATH before starting your tool).

> So, if there is a common spot in C:\cygwin\special_dir, then the PATH
> would need to be edited by 3rd party applications to make sure the dll
> could be found. Also, by using a common cygwin1.dll, installing software
> could change the DLL another vendor was tied to (patched cygwin) and
> break a previous installation.

Yowch.  If you distribute a patched cygwin1.dll, good luck to you!
Seriously.

> Finally, there is already a lot of applications that ship with
> cygwin1.dll in ther bin/ directory, and will probably continue to do so.

Yes.

> Again, my intentions here are not to bash cygwin. Eric Blake was kind
> enough to describe to me why cygwin acts the way it does, and from my
> understanding it makes perfect sense. However, I don't think as a Cygwin
> supporter that it should follow that it is possible to nicely distribute
> Cygwin in a 3rd party application when in reality it is not.

It *is* possible to nicely distribute Cygwin in a 3rd party application.
It may need some work to factor out the necessary functionality from
Cygwin's setup.exe so that the tool to provide this nice packaging is not
so heavyweight and can be integrated into other installers, but it's
certainly doable.

Again, I refer you to the above choice of which 3rd party to be, and leave
you with this final thought: all of the 3rd parties classified as 3PPs
followed the path of least resistance and quickest packaging.  To quote
an old American movie: "Big mistake. Huge.".
HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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