On Tue, Apr 04, 2006 at 11:44:47AM -0700, David Rothenberger wrote: >WinMain() in a program compiled with cygwin1.dll is no longer >getting passed the command-line from bash correctly with the >20060403 snapshot. It works fine with the 20060329 snapshot. > >This is the same problem mentioned in ><http://cygwin.com/ml/cygwin/2005-09/msg00298.html>. > >The same test case is attached here again (winCmdLine.c). I compile >it with "gcc -o winCmdLine winCmdLine.c" (note no -mno-cygwin).
This is due to recent changes which cause cygwin to stop filling out the command-line for cygwin1.dll using programs. We did this to fix the "long command line" problem. There is a crude workaround for the problem which reinstates the previous cygwin behavior but I really would rather not go that way. It would be nice if, just this once, we could make cygwin a little faster at the expense of programs which are using a non-linux-like interface. So, I'm thinking that if you want your WinMain or GetCommandLine using program to work with Cygwin 1.5.20 then you'll have to relink it. I realize that this is a major departure from previous stated goal of maintaining backwards compatibility but we've already broken that once in recent memory with the case of pure Windows environment variables so I think we probably will just take the logical next step and break things for WinMain and GetCommandLine as well. If there are a lot of programs out there which are using WinMain or GetCommandLine then I guess we'll hear about it. Otherwise, unless someone can convince me that this is a bad idea, Cygwin will start carrying a GetCommandLine substitute which regenerates the command line from the argv list. I have something ready to go in my sandbox now but I thought I'd hold off doing this in case someone had a valid objection to this approach. 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/