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. > 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 installation. 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: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
