Re: Augmenting cygwin woes

[Jeff Waller <jeffw at 141monkeys dot org>]

Christopher Faylor wrote:

>>>
>>>Hmm, but perhaps, this is the first guy to ask for it?  If that
>>>is the case, then I suggest a label for that column "First Requestor"
>>>which is kinda silly actually.  Since you'd want to contact
>>>everyone, not just him.  What does it mean anyway?
>>>
>
>I don't understand what the confusion is.  We're seeing a new take on
>the to-do list, apparently.
>
Yes looks like;  I took it to indicate a list of things that people had 
requested
though were not currently avaliable, but were in progress with the guy who
had volunteered to do them or had the best knowledge about the subject area
listed next to it.

>
>The majority of the submissions are from people who try to submit things
>like "Why don't you add joe to cygwin??????????????????????????",
>however we do get one or two people who submit items that actually have
>something to do with the stated purpose of the page.  The page is not an
>indication of anyone actively working on anything.  Hence the term "to
>do".
>
But I didn't find a page entitled "being done," so I assumed that "to do"
comprized both and only those things being actively addressed were listed.
Even when I reread the page with the knowledge of what it actually is
for, I still think it's nebulous.  Should there be such a "being done" 
page?  My
original intent was to first check to see that I wasn't duplicating 
something
that someone else had already started.

>
>
>I suggest that if you read the bottom of the page, where you get a
>chance to submit a suggestion, it might be a little clearer what this
>page is for.
>
>>>Ok, but you see the reason for it.  What, for instance, do you do if
>>>there is a program avaliable only for a previous version of cygwin that
>>>you want to use on the same machine as an installation of the newest
>>>version cygwin?  I understand that cygwin must act as a kernel of sorts
>>>to allow IPC and global resource allocation, etc.
>>>
>>As you understand that cygwin acts as a kernel of sorts, then it
>>follows that running two kernels simultaneously won't work :].
>>
>>The cygwin ABI has not regressed since B20.1.  There should be no
>>binaries that work under an older version that fail under a newer
>>version.
>>
>>So the answer to "what do you do if.." is you don't.  You backup your
>>old .dll and install the new one (from outside cygwin).
>>
>
>Right.  Newer cygwin versions are backwards compatible with older cygwin
>versions.  It's the law.
>
The same signatures, but what about the implementations? Or introduction 
of bugs?
Someone might be required to use say a buggy version 1.3.3 to run a program
because it implements a new feature, and now a few old programs that 
would have
been fine with 1.3.2 are now buggy.  Of course you'd be right in saying 
that this
is just like  the problems faced in coming out with a new OS based on 
say a new
version of glibc or a new kernel.

>
>
>However, you can force cygwin to use different shared memory regions if
>you either 1) configure with --enable-debugging or 2) set the CYGWIN_TESTING
>environment variable to some non-zero value.
>
>This may cause subtle failures with synchronization betwen two processes
>but it should be ok for testing.
>
Hmm not sure which is better, the pain of switching back and forth, or 
weird failures.



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple