Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 9 Sep 2005 21:46:35 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: please try latest snapshot
Message-ID: <20050910014635.GA25247@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <20050822181856 DOT GA6914 AT trixie DOT casa DOT cgf DOT cx> <20050910000630 DOT GA7820 AT tela DOT daveroth DOT dyndns DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050910000630.GA7820@tela.daveroth.dyndns.org>
User-Agent: Mutt/1.5.8i

On Fri, Sep 09, 2005 at 05:06:30PM -0700, David Rothenberger wrote:
>I'm having a problem with the 20050908 snapshot. I have been using
>my own compiled version of XEmacs 21.4 for some time and I
>frequently use the DDE client winclient. I noticed that this client
>started core dumping with recent snapshots.
>
>I did some investigation and found that winclient uses WinMain as
>it's entry point. With the latest snapshot, WinMain isn't getting a
>valid command-line, while it works just fine with the 20050828
>snapshot.
>
>A simple test case (winCmdLine.c) is attached.
>
>With the 20050828 snapshot, I get:
>
>% uname -a
>CYGWIN_NT-5.1 tela 1.5.19s(0.138/4/2) 20050828 19:27:12 i686 unknown unknown Cygwin
>% gcc -Wall -o winCmdLine winCmdLine.c
>% ./winCmdLine arg1 arg2
> arg1 arg2
>
>With the 20050908 snapshot, I get:
>
>% uname -a
>CYGWIN_NT-5.1 tela 1.5.19s(0.138/4/2) 20050908 23:01:39 i686 unknown unknown Cygwin
>% gcc -Wall -o winCmdLine winCmdLine.c
>% ./winCmdLine arg1 arg2

This should be worked around in the next snapshot.

The reason for the problem is that I changed cygwin recently so that it
knows when it is about to execute a cygwin program and avoided creating
a windows command line in that case.  This means that we can use much
greater command line lengths automatically but it also means that
programs won't see a "windows command line".

A workaround for this problem is to just build the program with
-mno-cygwin.  Another workaround is to just use
main (int argc, char **argv).

I realize, however, that there may be a few cygwin windows programs out
there which are using the Windows API or WinMain to get the command
line.  So, I changed cygwin to still create the windows command line
unless the program is mounted in a 'cygexec' directory.  However, a
cygwin program will now silently truncate the windows command line at
~32K rather than fail with an E2BIG when it hits that limit.

It's regrettable that we still need to encumber cygwin with the overhead
of building a command line for Windows now that the DLL finally has the
ability to detect when it is running a program which is linked to
cygwin1.dll.  But, we still need to preserve some kind of backwards
compatibility.

Thanks for the test case and for testing the snapshot.

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/