How do I get an old version of cygwin?

[Christopher Faylor]

[I held off sending this for a few days because I thought the thread would
die down but then I thought that some of the content might be useful,
so here it is]
On Wed, Jan 19, 2005 at 10:06:46AM -0800, Yitzchak Scott-Thoennes wrote:
>Gets kind of old to hear this "debated" over and over again when it's
>clear that the developers are not interested in the work involved.

cygwin-licensing was designed to discuss valid concerns.

I don't remember a case of someone looking at the cygwin code and saying
"I have looked at all of the places where there are potential conflicts
between different versions of cygwin and here is how I would handle
them."

For future mailing list spelunkers -- you don't win points by:

- making suggestions without investigating how things are done now
and assuming that the developers probably missed simple things

- asking for increasingly detailed explanations about the problems so
that you don't have to actually look at the source

- implying that it's something that is simple to do but the developers
are just mean,

- asserting that vendors absolutely need this functionality so that they
can all put as many versions of cygwin1.dll on a system as necessary
without worrying about other installations

I don't know if anyone remembers but many years ago, when there was a
new cygwin release, you'd have to rebuild things because the name of the
DLL changed every time.  That ensured that multiple versions of cygwin
could exist on the same system.  It also ensured that programs compiled
with different versions would not understand each other's ttys and might
not be able to pass command line arguments to each other and that /foo
meant different things to different programs running on the same
computer.

There was also a splinter project formed which had, as it's goal,
allowing multiple versions of a cygwin-like dll to co-exist.  Look
for it on sourceforge.  I don't think it's very active these days.

The problem here is that I can't think of any way of reliably dealing
with this problem which would not force an unpleasant discipline on the
cygwin developers, requiring them to always be sure not to break the
"cygwin abi" which deals with the various ways that cygwin programs
communicate with each other.  In fact, I've made a couple of changes in
the latest snapshots which would have taken a lot more time if I had had
to make sure that cygwin 1.5.12 could cleanly interact with cygwin
1.5.13.

You *can* do some things to the DLL, such as those which are used by the
test suite which allow two versions to coexist without causing problems.
However, the test suite is careful to put a barrier in the middle between
processes which are being tested (thanks to DJ Delorie) so that there
are no problems with command-line argument passing or with cygheap
inheritance.  So, this is not a general solution.

If we were to implement some sort of "good enough" scheme, you can be
sure that it would elevate the amount of tech support that we received
here.  However, anyone who really wants to do something similar to the
test suite can use the same mechanism.  Just don't send your problem
reports here.  If you want to use this mechanism, then you should be
savvy enough to know how to deal with problems when they occur.

If someone really does have a brilliant idea on how to deal with this
problem, please demonstrate your brilliance with a patch.  If there
is an elegant solution to this problem then source code is the way
to demonstrate it.

cgf

--
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/