X-Spam-Check-By: sourceware.org
Date: Tue, 11 Apr 2006 10:19:21 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin backwards compatibility break with WinMain and    GetCommandLine (was Re: WinMain() not getting cl...)
Message-ID: <20060411141921.GA15620@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20060404184447 DOT GA4824 AT tela DOT daveroth DOT dyndns DOT org> <20060410013414 DOT GA20557 AT trixie DOT casa DOT cgf DOT cx> <Pine DOT GSO DOT 4 DOT 63 DOT 0604100927270 DOT 20193 AT access1 DOT cims DOT nyu DOT edu> <20060410173850 DOT GA19752 AT trixie DOT casa DOT cgf DOT cx> <Pine DOT GSO DOT 4 DOT 63 DOT 0604101352460 DOT 20193 AT access1 DOT cims DOT nyu DOT edu> <443AA212 DOT DF9AB154 AT dessent DOT net> <Pine DOT GSO DOT 4 DOT 63 DOT 0604101447170 DOT 20193 AT access1 DOT cims DOT nyu DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.63.0604101447170.20193@access1.cims.nyu.edu>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 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.  Programs linking with the new version of Cygwin will
>>>have that function, but due to API changes, may not work with older
>>>DLLs.  Or am I missing something?
>>
>>It should work out like this:
>>
>>Linked against <1.5.20, Run against >=1.5.19: calls kernel32's GCL()
>>and won't work
>>
>>Linked against <1.5.20, Run against <1.5.19: calls kernel32's GCL() but
>>the win environment exists, success
>>
>>Linked against >=1.5.20, Run against any version: calls libcygwin's
>>static GCL(), which works in any circumstance
>
>I'm worried about the case
>
>Linked against >=1.5.20, Run against <=1.5.19: calls libcygwin's static
>GCL, which works, but fails because 1.5.20 (or 1.5.21, etc) has an
>extra API function that now gets invoked by the code, but is missing
>from 1.5.19 and earlier -- BOOM.
>
>IOW, the infamous "Procedure entry point ...  couldn't be found" popup.

So you're thinking that a program which has had no other changes, and
hasn't been recompiled, is going to somehow pull in newer functions from
cygwin1.dll?

Please provide examples of how that could happen.

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/