X-Spam-Check-By: sourceware.org Date: Mon, 10 Apr 2006 15:55:02 -0400 (EDT) From: Igor Peshansky Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com Subject: Re: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...) In-Reply-To: <20060411141921.GA15620@trixie.casa.cgf.cx> Message-ID: References: <20060404184447.GA4824@tela.daveroth.dyndns.org> <20060410013414.GA20557@trixie.casa.cgf.cx> <20060410173850.GA19752@trixie.casa.cgf.cx> <443AA212.DF9AB154@dessent.net> <20060411141921.GA15620@trixie.casa.cgf.cx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com 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 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? Huh? That's the point -- it *has* to be recompiled to get the new GetCommandLine implementation from cygwin.a... > Please provide examples of how that could happen. I compile program A (which uses GCL) under 1.5.18 and release it. It doesn't work properly on 1.5.20+ (because it calls the kernel's GCL). I then recompile it under 1.5.20 to pull 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? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha@cs.nyu.edu | igor@watson.ibm.com ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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/