Staring at some Process Monitor logs I noticed that dirmngr wastes 3-4 seconds trying to connect to localhost:9050 and localhost:9150 looking for tor. After adding no-use-tor to dirmngr.conf dirmngr starts reasonably fast.

In T7379#195089, @ikloecker wrote:

Kleopatra does now read the certificates from the card and import them itself instead of relying on gpgsm --learn-card.

since nothing was changed, that's a wontfix…

Remove the lines starting with ShowResultsAfter[...] in kleopatrarc

I have built the run-* test programs of gpgme for Windows. run-keylist --cms --secret takes about 23 seconds. 3.7 seconds are gpgme initialization/setup (gpgconf --list-dirs, gpgconf --list-components, gpg --version, gpgsm --version, gpgconf --version). Most time (2 x 6-8 s) is lost starting gpg-agent and dirmngr. (keyboxd is not enabled here.)

I would suggest to use something like "Kyber 768 + brainpool P 256" because parentheses might be interpreted tha this is an alias for Kyber,

commands with -v

Please always add -v t commands like "gpg --decrypt test.txt.gpg". To decide whether this is smartcard or gpg-agent releated, I need to see a log file form gpg-agent and scdaemon. The latter is more important. I would suggest "debug ipc,app,cardio"

That works using a gpgconf.ctl file side by side to gpgconf{,.exe}

Closing. I don't think we need this "Klammer-Ticket" anymore and it's cluttering my task list.

I'm not working on this anymore. Kleopatra should be prepared for using VSD, GPD, and Gpg4win in parallel (provided they use different homedirs). What's left is the actual parallel installation which might be solved in part by using NSIS for Gpg4win and MSI for VSD/GPD. I'm not sure how the parallel installation of different versions of gnupg is solved, but I guess Werner has that covered.

For KF5-based builds this is resolved because the improved heuristic for detecting light high-contrast themes (like "Desert") is used for VSD 3.3 and Gpg4win 4.4.

For simplicity (and because I think entering tab characters isn't really essential for the notepad) I decided to go with the first solution.

Can't you just use file descriptors everywhere and use _get_osfhandle. That is what I am used to seeing in Windows code in Gnulib (although I do not touch it much).

Regarding 64bit handles https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication
tells us:

Ready for testing.