X-Spam-Check-By: sourceware.org Message-ID: <443AA212.DF9AB154@dessent.net> Date: Mon, 10 Apr 2006 11:21:06 -0700 From: Brian Dessent MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...) References: <20060404184447 DOT GA4824 AT tela DOT daveroth DOT dyndns DOT org> <20060410013414 DOT GA20557 AT trixie DOT casa DOT cgf DOT cx> <20060410173850 DOT GA19752 AT trixie DOT casa DOT cgf DOT cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 Brian -- 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/