npth_t is untouched for Windows 64-bit.

assuan_sock_accept approach is taken in gnupg master.

gniibe/t6606 patches are all pushed into master.

Applied: rGb8c5d99406c9: gpg,agent,kbx,sm,scd,tpm2d,g13: Use assuan_control.

In T6606#173044, @gniibe wrote:

More care is needed to be perfect; There are places in GnuPG where assuan_sock_connect may be used before syscall clamp set up (after the first assuan_sock_bind failure).

Applied to master.

Applied the changes for libassuan T6487 into gniibe/t6606.

Pushed the change in gniibe/t6606 branch.

Another approach would be:

• Use assuan_sock_accept which has consistent API with gnupg_fd_t

On 64-bit Windows, the situation now is:

Use of FD2INT for the first argument of select is semantically not good. It's the number of file descriptor. When we use FD2INT here, the type is converted to 64-bit integer, then implicitly demoted to 32-bit integer. We need new macro, say, FD2NUM to convert FD into 32-bit integer.
<--- done in: rGea1935252e28: commond: Introduce FD2NUM to express conversion to number of fds.

Here is a test program for 64-bit Windows to see how cast works:

#include <stdint.h>
#include <stdio.h>

The case in check_special_filename is fixed. So, there is no cases in GnuPG where the value of out of range is silently converted to wrong value.

Remaining places are:

• common/sysutil.c debug output to format HANDLE --> T6597
• common/sysutil.c iobuf_get_fd and its use cases --> T6580
• agent, kbx, scdaemon, dirmngr: socket and FD2INT/INT2FD --> T6598

Except a case, all use cases of translate_sys2libc_fd_int is with a result of integer from command line argument.

Changes are pushed.

We need to keep the gpgtar part of commit in rG2756147e392c: gpg,sm,tools: Use string for option --*-fd..

The changes are intrusive to other implementations (POSIX and Windows 32-bit).
So, I revert the changes of replacing translate_sys2libc_fd_int.

I don't argue about the technical necessity for the change. I agree the fact it works (without such changes).

Just to clarify this change for readers not accustomed to Windows internals: This function was used to translate the file descriptor as passed to gpg (which is a HANDLE) to the libc file descriptor as used by stdio. Obviously we won't anymore work with stdio file descriptors in the future but use the Windows32 API (ReadFile et al). libc fds 0,1,2 are handled in a special way on Windows.

Fixed in master.

The use cases are:

• oPassphraseFD for gpgsm, gpg
• oStatusFD for gpg-auth, gpg-wks-client, gpg-card, gpg-pair-tool, gpgtar, gpgconf, gpgsm, gpg, gpgv
• oLoggerFD for gpgsm, gpg, gpgv
• oAttributeFD for gpg
• oCommandFD for gpg
• oOverrideSessionKeyFD for gpg

to give you any help I would need to know the exact error. I can only tell you that this is not a problem related to Gpg4win something else must be messy on your system. The Uninstaller of Gpg4win cleans up all registry keys that do not contain user config and all files should be removed unless some other process on the system interferes.

Added variable value

set language
LANGUAGE=en_US

I launched the Kleopatra again. I did not notice any changes.

Thanks for your report. Yes this is sadly a known issue. Our backend system has it's own localization that uses the system language and does not care about the Kleopatra configuration.