X-Spam-Check-By: sourceware.org Message-ID: <43E2B779.4371E33B@dessent.net> Date: Thu, 02 Feb 2006 17:52:57 -0800 From: Brian Dessent MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: mismatched dll References: <020220062158 DOT 387 DOT 43E28079000ACE870000018322007507440A050E040D0C079D0A AT comcast DOT net> <20060203013712 DOT GC17485 AT brasko DOT net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Bob Rossi wrote: > Here's another question I have (sorry). Why wouldn't it be acceptable to > have to (different version) cygwin1.dll's running on a single system? > That is, 2 completely different Cygwin environments? So, all programs > that link against the same cygwin1.dll are in one Cygwin environment. If > there is another version of the cygwin1.dll, and programs link against > it, they would be in another Cygwin environment, completely independent. It *is* possible to create two Cygwin DLLs that can co-exist. But to do so requires much more than just naming them differently. The source code must be modified to use a different filename/identifier for the shared memory region, as well as different registry keys for the mount table. The Cygwin testsuite does a limited version of this to allow running the just-built Cygwin DLL for the purposes of executing the tests, from within the developer's existing Cygwin environment. So yes, it can be done. But it is a very bad idea to do so. If you made two DLLs that were isolated in this way they would be truly isolated -- you could not send signals from one to the other, they would not see each others processes in their PID tables, and so on. It would be the absolute worst way to have two sets of software interact. This is ESPECIALLY true when the code goes to great lengths to be backward compatible. The idea is that you can ALWAYS replace an existing cygwin1.dll with a newer one, without recompiling the old apps that were linked against the old version of the DLL. You of course can't go in the other direction (using an older DLL with newer .exes) but this backwards compatibility is in theory good all the way back to version 1.0.0 from circa 1998-ish. So there is no reason why you should ever need two Cygwin DLLs in the first place, because you can always replace an older one with a newer one. If you are writing an installer of a third party application the basic logic should thus be: Is a cygwin1.dll already on the system somewhere? Yes: Is it newer than mine? Yes: Install my .exe, but do not install my cygwin1.dll, use the existing one. No: Prompt user of the situation, and either bail or overwrite older DLL with newer DLL. No: Install my DLL. Essentially, you must ensure that if a Cygwin DLL already exists you either use it as-is or replace it with a newer one. Never install a second copy, and never overwrite a newer one with an older verison. Brian -- 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/