This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: please try latest snapshot


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]