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?

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

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

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

Next, putting cygwin1.dll in a common place could prove to be very
problematic. If it is not in the directory where the program is
executed, then it needs to be on your path. 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

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

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.

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]