X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org X-Yahoo-SMTP: jenXL62swBAWhMTL3wnej93oaS0ClBQOAKs8jbEbx_o- Date: Thu, 3 Mar 2011 11:45:19 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Doubtful about unison Message-ID: <20110303164519.GA26936@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4D6BFD09 DOT 8020600 AT gmx DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On Thu, Mar 03, 2011 at 02:46:59PM +0100, Olivier Lefevre wrote: >On 3/3/2011 8:06 AM, Andy Koppe wrote: >>> In a slightly different line of thought, isn't it rather brittle of >>> Cygwin that a minor upgrade (I was already at some 1.7 version) >>> breaks applications? Think, a contrario, of how you can still run >>> ancient Windows apps on XP. >> >> The problem you had was a case of broken forward compatibility, >> whereas your Windows example is talking about backward compatibility. > >Yes, you're right, I had it mostly backwards. > >However in this case it seems the problem wasn't that Unison used new >features of Cygwin but that somehow the layout of the Cygwin DLL had >changed, in a way that broke applications. I am not much of a system- >level programmer but in higher-level languages you'd expect things to >keep working as long as functionality (i.e., method signatures) has not >changed or that the new functionality is a strict superset of the older >one. I am sure I am betraying a woeful ignorance of C-level programming, >of linkers etc (which maybe isn't such a wise thing to do in a public >forum; oh well) with this question but isn't there a way to pin down >entry points and suchlike to ensure better forward compatibility? Would >rebaseall have helped? This is just for my enlightenment: I am not >suggesting you twist yourself into pretzel shapes trying to ensure >stellar forward compatibility; I suspect Cygwin programming is tricky >enough as it is. I can't make much sense of the above. It seems like gobble-de-gook. Except for certain very rare cases, old programs should work fine with new Cygwin DLLs. We don't "change the layout" in a way that breaks compatibility for old programs and new DLLs. Since we do continually augment the Cygwin DLL by adding new features and new functions, a program which is linked with a new Cygwin DLL may make use of the new functions. There isn't anything, short of time travel, that the Cygwin DLL can do at that point to make the program backwards compatible. It's possible that a program might want to take newer features into account but I think it would be rather daft and counter-productive for anyone maintaining a program to worry about that scenario. Windows itself offers new APIs in newer OSes. So a program built to work on Windows 7 may not work on Windows XP. That's just the way the world works. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple