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. To explain in the context of the actual call chain: - I have opam.exe (compiled with mingw-w64), which is calling SetErrorMode in main - It's calling ocamlc.exe (in PATH) which requires the zstd DLL, but that has not been put in PATH - A direct call - not via Cygwin - to ocamlc -vnum therefore returns an exit code - Another call, already there from the Unix side, instead does sh -c "ocamlc -config | sed ......." but Cygwin has then _removed_ the calling applications preference Thanks, David -- 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
