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

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Feb 2 12:55:09 GMT 2024


On Feb  2 09:43, David Allsopp via Cygwin wrote:
> On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> >
> > The behaviour changed in 2020
> >
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
> >
> > not without a discussion
> >
> > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
> 
> Aha, thank you! (congrats on the 3.5 release, in passing, btw).
> Definitely not a regression, then (subject edited).
> 
> However, this patch came from MSYS2, and subsequently they seem to
> have found it problematic for the same reason as me
> (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
> and have just recently reintroduced the flag
> (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
> to control it.
> 
> The reasoning in
> https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
> valid now as it did in 2006.
> 
> Is it possible to revisit having the flag, or even just reverting the behaviour?
> 
> FWIW, it's been "hurting" us over in OCaml-land since zstd support was
> added roughly a year ago - configure can tell us that mingw-w64's zstd
> is available, but woe betide us if we run the test program to see if
> it actually works, but the user forgot to add the sys-root into PATH,
> because at that point the CI system is down...

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?


Corinna


More information about the Cygwin mailing list