Mail Archives: cygwin/2006/04/10/09:48:27
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:
typedef LPTSTR WINAPI (*GCL_PTR)(void);
LPTSTR WINAPI cygwinGetCommandLine(void) {
HMODULE cygDLL, winDLL;
GCL_PTR cygGCL, winGCL;
cygDLL = GetModuleHandle(TEXT("cygwin1.dll"));
cygGCL = (GCL_PTR) GetProcAddress(cygDLL, TEXT("GetCommandLine"));
if (cygGCL != NULL) return cygGCL();
winDLL = GetModuleHandle(TEXT("kernel32.dll"));
winGCL = (GCL_PTR) GetProcAddress(winDLL, TEXT("GetCommandLine"));
if (winGCL != NULL) return winGCL();
return NULL;
}
and prefacing the rest of the program by:
#define GetCommandLine cygwinGetCommandLine
Barring some typos in the above, it should work.
WinMain would be a bit harder to emulate, but still possible using the
same techniques as above.
David, could you try this with your testcase and see if my claim is
correct?
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 -