The GetCommandLine/WinMain "problem"

[Larry Hall]

Christopher Faylor wrote:
> The problem which was recently reported in the cygwin list where
> good-old "GetCommandLine" no longer works (as invoked prior to calling
> WinMain) is due to changes that Corinna made to spawn_guts.  She made it
> so that if cygwin detects that a to-be-execed process is a cygwin
> process it does not fill out the windows command line.
> 
> I had resisted making this optimization, probably for exactly the case
> of GetCommandLine, but, now that it's there, I am loath to change it.  I
> like the idea of spawn_guts not going to the effort of creating a
> windows command line when it knows it shouldn't have to.
> 
> I don't know why the original creators of Cygwin decided that they had
> to implement WinMain handling when they were trying to create a system
> that built GNU tools that didn't use WinMain, but, regardless, I am
> thinking that maybe we should deprecate WinMain, GetCommandLine, and
> GetEnvironmentVariable and friends.  I think that there probably aren't
> very many programs out there which use these.
> 
> What we could do is export versions of these in libcygwin.a (not
> necessarily in cygwin1.dll).  A Cygwin version of GetCommandLine[AW]
> would concatenate the contents of __argv and return a string.
> GetEnvironentVariable could do the same thing.
> 
> This is a radical departure from our previously stated goal of "newer
> cygwin's always work" but, frankly, I'm getting very tired of hearing
> how slow cygwin is (read the git mailing list sometime) and I am even
> more tired of making accommodations which slow things down for people
> who are using Cygwin in ways that aren't in line with it's stated goals.
> 
> Does anyone think that requiring people to relink their apps if they
> want to use these Windows-isms is a very bad idea?  FWIW, I discovered a
> way around the problem that Corinna was fixing with her spawn_guts
> changes and Corinna has a patch waiting in the wings to implement it
> but...  I'd rather not go with the patch.  I'd like cygwin programs to
> just not worry about the windows command line (or windows environment
> variables) at all.


I think this is reasonable, at least to try.  As long as there is a simple,
transparent step of "just relink and things will work as expected again",
then I don't see a problem.  I would, however, recommend keeping the
alternative patch waiting in the wings in case all hell breaks loose and
the pain experienced on the Cygwin lists start to outweigh the benefits.
If that point is reached, we could revert the behavior and stall the change
until Cygwin 2.0.  If this situation arises, there's no reason Cygwin 2.0
can't be a "sooner" rather than "later" thing either.  It might be a good
argument to start planning some serious house-cleaning. :-)  But if we can
avoid all the other issues that 2.0 would bring and just introduce this
performance improvement, so much the better.  Thinking along that line, do
we know what benefits we get from this change, such as improved performance?
Can it be quantified?

-- 
Larry