Mail Archives: cygwin/2011/03/03/11:45:34
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
- Raw text -