Mail Archives: cygwin/2006/03/28/16:10:07
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 AT Gmail DOT 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/
- Raw text -