On 2024-02-01 01:18, David Allsopp via Cygwin wrote:
On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote:
On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
Starting with this very trivial C program:

#include <stdio.h>
#include <zstd.h>

int main(void) {
    printf("Zstandard v%d\n", ZSTD_versionNumber());
}

and compiling with

x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd

when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The code execution cannot proceed because
libzstd-1.dll was not found. Reinstalling the program may fix this
problem."

My question is not how to fix the problem (I'm well aware of that),
but rather why that message is being displayed at all, and is it a bug
in Cygwin somewhere? All I could find Googling was previous
suggestions that Cygwin routinely calls SetErrorMode with, amongst
other things, SEM_FAILCRITICALERRORS with the intention of suppressing
this dialog.

Is that correct, and if so is this just me? :o)

Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
I also get the same popup if I run C:\cygwin64\bin\sh -c
"/cygdrive/c/path/to/test" either from a Command Prompt or even from
"Start -> Run". Running this via "sh" called from a non-Cygwin process
(itself invoked from a Command Prompt) which has also called
SetErrorMode is how I hit this.

Better to let you know that there is a problem, and what the problem is, so you
can fix it!

Thank you, but no - as I made clear by:

My question is not how to fix the problem (I'm well aware of that)

I'm fully aware what has caused the issue to arise, and how to fix it
- that's not the issue. The problem is that according to previous
messages, and the Cygwin code, my impression was that mintty / bash /
sh (*Cygwin* programs) calling this executable should be returning an
exit code here, not freezing on a message dialog. The problem appears
to be a bug in the Cygwin DLL, and from previous messages on the list,
my question is whether it's a regression, and can be fixed.

The reason it's a problem is, say, a script _in Cygwin_ which is
handed a command to run, runs it, and is then completely blocked by
that popup dialog. It's the responsibility of the _caller_ (a Cygwin
program) to indicate the mode in which a program is executed - the
message box may be owned by the program called, but it's caused by it
being loaded, before it has a chance to run any code.

My understanding, based on this line:

https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721
in dll_crt0_0

is that Cygwin executables (in this case mintty / bash / sh, etc.)
should be running with SEM_FAILCRITICALERRORS enabled, following the
best practice recommendations in
https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode
and that that setting should be correctly inherited by processes they
call (including non-Cygwin ones).

Some ancient history, reporting my same issue in 2004:
https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this
thread from 2006
https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly
indicating that that line dcrt0.cc is there precisely to stop this
popup.

I do not see the problem if a native MS Windows program is not properly installed with native MS Windows library dependencies and MS Windows displays a popup to inform the user of the missing dependency. Developer/maintainer/packager/distributor defects are never a downstream issue, they need to be addressed by the party who caused the failure!

There seems to be a conflict here with some native MS Windows program users wanting those native MS Windows programs to be able start a debugger and others wanting a CLI failure message.

ISTM if native MS Windows programs want specific native MS Windows behaviour, they should set that up before, at, or shortly after startup, as Cygwin does for its own programs, not rely on a foreign invoker doing so for them.

Could those native MS Windows programs not be run from a native MS Windows shell or wrapper script to ensure the desired behaviour?

Or just do not run native MS Windows programs, and find or build a Cygwin script or program to perform the desired function: that's the Cygwin way to avoid native MS Windows issues! ;^>

--
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                -- Antoine de Saint-Exupéry

--
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

Reply via email to