This is the mail archive of the
mailing list for the Cygwin project.
- From: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>
- To: "Cygwin-Apps" <cygwin-apps at cygwin dot com>
- Date: Fri, 18 Jul 2003 20:32:14 -0500
- Subject: RE: SetupXP
> >> Perhaps we can compromize on "Cygwin Setup -
> >> CurrentTitleOfPage"?
> > That would probably work. I've seen one installer that did that, and I
> > that my Platform SDK help browser thing does that too.
> OK, I'll put together a patch+ChangeLog for this tonight (GMTDT, i.e. +1)
> unless you beat me to it.
Looks like I didn't ;-).
> >> "make LogFile::exit() not exit if exit_code == 0":
> >> I don't understand the reasoning behind this change. Can you explain?
> > This is one small step for man towards moving the app's exit()ing and UI
> > interaction out of the LogFile class. I'm only changing the success (==0)
> > case currently because there's only one code path that succeeds, while
> > are several places in the code (and in the UI) that do this:
> > "LogSingleton::GetInstance().exit(1);". Eliminating those will require
> > extensive changes.
> Wait! The status quo must remain, until we have confirmed evidence that
> static destructors do always run on exit from -mno-cygwin programs.
As Rob said, he's said that too. What am I missing? Neither of LogFile's nor
LogSingleton's destructors do anything, and this change doesn't remove the
"theLog->exit (0);" at the end of main() (the only place its' called with 0),
so... where's the connection?
> Then and
> *only* then can we move to using simple CRT exit().
Um... too late, that's exactly what LogFile::exit() does already. Or, I'm not
advocating replacing LogSingleton::GetInstance().exit(1)'s with ::exit(1)'s, if
that's what you're thinking.
> Until then I don't think
> there is any harm in using constructs like
Well, the harm is mainly in its use spreading. The longer it sits, the more
entrenched it will become, and the larger the patch required to fix it.
Gary R. Van Sickle