The GetCommandLine/WinMain "problem"

[Larry Hall]

Christopher Faylor wrote:
> On Wed, Apr 05, 2006 at 08:50:51PM -0400, Larry Hall wrote:
>> 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?
> 
> I don't really know, Larry.  I probably slowed Cygwin down some by
> having it look to see if a to-be-spawned executable is using
> cygwin1.dll.  So, Corinna's change may just get back a fraction from
> that change.


OK, so it doesn't sound like this change is motivated by any immediate
performance improvements.  I guess the argument for it is just better
"positioning" then, which is fine.  If Cygwin can't grow in the direction
it needs to go with things like this in the way, a change makes sense.


> Corinna mentioned 2.0, too, but that really runs counter to what I was
> thinking.  I'm trying to improve things for the normal cygwin user while
> impacting a minority of "abnormal" users.  Moving to Cygwin 2.0 would,
> of course, mean impacting everyone severely.  And, possibly it would impact
> Corinna and me most of all.  I am not ready for that quite yet.


Right.  I'd agree that this is a small enough change that there should be
minimal pain.  If that turns out not to be true, I guess the fallback would
be to just yank it again and "schedule" a release to reinstate it with a
clear migration plan.  That could be, but isn't required to be, 2.0 (which
would obviously have to have a similar, and likely more extensive, migration
plan).


-- 
Larry