This is the mail archive of the
mailing list for the Cygwin project.
Re: Issue with run.exe and PWD with spaces since last update (Cygwin 1.7.21)
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: The Cygwin Mailing List <cygwin at cygwin dot com>
- Date: Wed, 17 Jul 2013 10:20:38 -0400
- Subject: Re: Issue with run.exe and PWD with spaces since last update (Cygwin 1.7.21)
- References: <295777180 dot 20130716202913 at mtu-net dot ru> <20130717125916 dot GB21347 at calimero dot vinschen dot de> <51E69DE2 dot 10008 at cwilson dot fastmail dot fm> <20130717134532 dot GC32258 at calimero dot vinschen dot de> <51E6A3DB dot 7050605 at cwilson dot fastmail dot fm> <20130717141042 dot GE32258 at calimero dot vinschen dot de>
On 7/17/2013 10:10 AM, Corinna Vinschen wrote:
Uhm. In that case, if ew *really* think your tools are the only
affected ones, Why do we bother to fix libcmain.c? Can't you then
simply provide your own main() in case of building for Cygwin?
Perhaps, but I'm not sure of the ramifications. I think if you have a
main() then you're going to get STD_HANDLES. Plus there's the whole
concern about launching run.exe itself without a cmdbox, when it is
used as a shortcut target.
This whole entrypoint thing is tied up in that, or at least it used to
be. Now, that may ONLY apply to the mingw-compiled version, in
which case I could do a
int main (int argc, char** argv)
return realmain(argc, argv);
and avoid the -e WinMain@16 link argument. (Except I think I arrange to
only do -e WinMain@16 on mingw...hmm...)
If you look closely at WinMain, it basically parses the result from
GetCommandLine() into argc,argv, and then delegates. The only
conceivable reason to do that, rather than just have a main(), was if
you NEED to use WinMain() as the entry point for some other reason. Like
ensuring that you "work" when compiled as a non-console app and don't
pop up a dosbox...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple