Mail Archives: cygwin/2006/04/10/14:11:03
On Mon, 10 Apr 2006, Christopher Faylor wrote:
> On Mon, Apr 10, 2006 at 09:48:10AM -0400, Igor Peshansky wrote:
> >On Sun, 9 Apr 2006, Christopher Faylor wrote:
> >
> >> 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.
> >
> >One argument against doing this is that people will now have to build and
> >distribute 2 versions of each such program -- one that works on 1.5.20,
> >and one that works on all previous versions of Cygwin. However, I think
> >there *is* a way of writing the program so that it will work on both
> >versions, by using something like the following (untested) function:
>
> This is not a problem. GetCommandLine won't live in cygwin1.dll. It
> will live in libcygwin.a. So, once linked, the binary will work with
> any version of cygwin.
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?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT 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/
- Raw text -