Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

David Allsopp david@tarides.com
Fri Feb 2 13:35:19 GMT 2024


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


More information about the Cygwin mailing list