On Feb 2 13:35, David Allsopp via Cygwin wrote: > Jon Turney via Cygwin wrote: > > > > I'm sympathetic, and personally I would prefer to revert the patch and > > > stick to SEM_FAILCRITICALERRORS by default. > > > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > > do the "right thing", with different definitions of "right", when in > > > fact the executable in question can easily call SetErrorMode by itself? > > > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > > get the behaviour you want? > > Ah, but that's how I hit this (and started digging further) - > precisely because the non-Cygwin program I'm using _has_ called > SetErrorMode and its direct calls to the faulty program _are_ doing > what's wanted (no popup dialog) but the calls which happen via Cygwin > are then torching that preference. > > Not really suggesting it be done this way (it feels more complicated > than just reverting the change), but in some ways perhaps Cygwin > should be using GetErrorMode on startup and instead of not inheriting > it, ensuring that it sets whatever it received? i.e. just before the > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > error mode (for that thread only) to the value read at startup, calls > CreateProcess and then sets the error mode back.
This sounds like a good ide, but... Is it actually a safe bet that the error mode set by SetThreadErrorMode is then propagated as process error mode to the child process? I have to ask that because Microsoft conveniently forgot to document this scenario in the MSDN docs. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
