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?


Igor Peshansky wrote:

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.


I was following this thread and time will tell. Something you're maybe not aware of that the cygwin1.dll soon will be distributed to thousends of people who didn't even heard about cygwin. How come?
You may have heard about BOINC if not take a short look @ http://boinc.berkeley.edu/
It is used to run Linuxcode inside Windoze. For exaple the burp project will use it to run povray on windoze. http://burp.boinc.dk (Don't waste your time visiting the page it is offline today because a server update). I can imagine a lot of problems resulting from this for people using cygwin but donate there idle cpu time to number crunching when there two different versions. Let's wait and C ...


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



-- And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

Alexander J. Herrmann
Analyst/Programmer
http://www.aiengine.org
Email: Ping2Weltall@Gmail.com


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