[snip] > >> Perhaps we can compromize on "Cygwin Setup - > >> CurrentTitleOfPage"? > > > > That would probably work. I've seen one installer that did that, and I > see > > 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 > there > > are several places in the code (and in the UI) that do this: > > "LogSingleton::GetInstance().exit(1);". Eliminating those will require > more > > 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 > LogSingleton::GetInstance().exit(1). > 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 Brewer. Patriot.