On 64-bit Windows, the situation now is:

I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.

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>

yeah, sorry, didn't test different key types yesterday.
NIST encryption keys do not work either, so only RSA encryption keys can be moved with Kleopatra to a smart card in gpg4win 4.2.0.
I can confirm that authentication keys work.

Found this one in Gpg4win-4.2.0-beta384:

There are some more surprising results like on my windows test keyring it would always report "5 new signatures" regardless of how often I ran the script ;)

Update the patch to allow --compatibility-flags hashing-in-parallel.

In T6379#172803, @ebo wrote:

Noticed in gpg4win 4.2.0-beta373:

For Brainpool and ed/cv25519 keys it is not possible to move a subkey to a smart card with Kleopatra. The error message is "invalid value".
Moving the main key works, though. The command line works for all keys types, of course.

Problem with SHA-256 on x86-64 is that it took long time for Intel to introduce SHA acceleration (SHA1 & SHA256) to their main CPU products.

Noticed in gpg4win 4.2.0-beta373:

😂 I literally laughed when I saw this. You are taking this so much further and faster then I expected. Great job!

Current progress, the viewer now support viewing embedded calendar events, embedded emails and embedded calendar events in an embedded email

Normal priority to get the _1_ removed when no folder with the same name already exists in that location.

Strangely enough this does not happen on linux. Maybe related to the KMime changes we have there?

For S/MIME archives the output for e.g. testfolder.tar.gz.p7m is now named "testfolder.tar.gz_1_/testfolder" with the "_1_" even added if there is no "archive.tar.gz"