user experience matters.
Before you ask, yes, I did post this to the cygwin-xfree mailing list.
However I am not getting anywhere there. So I am interested in the thoughts
of the wider, beyond X11, Cygwin community on backwards compatibility.
As I mention in my response to the cygwin-xfree thread y
Greetings, Laurens Blankers!
> I was wondering what the Cygwin community thinks about maintaining
> backwards compatibility, especially regarding configuration files when
> updating or changing a package. As a long time Debian user I have grown
> accustomed to upgrades going v
Hi,
I was wondering what the Cygwin community thinks about maintaining
backwards compatibility, especially regarding configuration files when
updating or changing a package. As a long time Debian user I have grown
accustomed to upgrades going very smoothly, backwards compatibility with
Just to close the loop on this subject: Corinna more or less convinced
me that breaking backwards compatibility isn't a good idea at this
time.
So, I've introduced the previously-mentioned kludge into cygwin sources.
So, recent snapshots have reverted to the slow method for filling o
Just a thought
Since this could potentially cause some misunderstanding, what about
bumping the Cygwin DLL version number to 1.6.0? That way there could
be some sort of statement to the affect that apps requiring these
functions should be relinked with 1.6.0 when it's released. It's
semantic
ull in the new libcygwin.a. However,
>this also pulls in whatever new functions are in cygwin1.dll, so that
>program A now doesn't work with <1.5.20. Am I missing something?
I was only talking about the simple act of relinking a program, not
recompiling everything. However,
On Tue, 11 Apr 2006, Christopher Faylor wrote:
> On Mon, Apr 10, 2006 at 02:52:04PM -0400, Igor Peshansky wrote:
> >On Mon, 10 Apr 2006, Brian Dessent wrote:
> >> Igor Peshansky wrote:
> >>>If GetCommandLine lives in libcygwin.a, then programs linked on older
> >>>versions of Cygwin will not link
On Mon, Apr 10, 2006 at 02:52:04PM -0400, Igor Peshansky wrote:
>On Mon, 10 Apr 2006, Brian Dessent wrote:
>> Igor Peshansky wrote:
>>>If GetCommandLine lives in libcygwin.a, then programs linked on older
>>>versions of Cygwin will not link that function in, and thus won't work
>>>with the new DLL.
On Mon, 10 Apr 2006, Brian Dessent wrote:
> Igor Peshansky wrote:
>
> > If GetCommandLine lives in libcygwin.a, then programs linked on older
> > versions of Cygwin will not link that function in, and thus won't work
> > with the new DLL. Programs linking with the new version of Cygwin will
> > h
Igor Peshansky wrote:
> If GetCommandLine lives in libcygwin.a, then programs linked on older
> versions of Cygwin will not link that function in, and thus won't work
> with the new DLL. Programs linking with the new version of Cygwin will
> have that function, but due to API changes, may not wor
revious cygwin behavior but I really would rather not go that way. It
> >> would be nice if, just this once, we could make cygwin a little faster
> >> at the expense of programs which are using a non-linux-like interface.
> >>
> >> So, I'm thinking that if y
er
>> at the expense of programs which are using a non-linux-like interface.
>>
>> So, I'm thinking that if you want your WinMain or GetCommandLine using
>> program to work with Cygwin 1.5.20 then you'll have to relink it. I
>> realize that this is a major dep
etCommandLine using
> program to work with Cygwin 1.5.20 then you'll have to relink it. I
> realize that this is a major departure from previous stated goal of
> maintaining backwards compatibility but we've already broken that once
> in recent memory with the case of pure W
ake cygwin a little faster
at the expense of programs which are using a non-linux-like interface.
So, I'm thinking that if you want your WinMain or GetCommandLine using
program to work with Cygwin 1.5.20 then you'll have to relink it. I
realize that this is a major departure from previo
14 matches
Mail list logo
