I don’t think it has anything to do with algorithm, bcoz Kleopatra and Gnu (command mode) purely works fine with me EXCEPT in Outlook. I suspect it’s something to do with Outlook Plugin.
PS：I’m now using curve25519, the PGP key has a password to protect itself.
Hi, sorry you had to wait so long for an answer but we had public holidays over easter…
It will take time to check the logs. Yes, this has certainly not anything to do with the algorithm.
And GpgOL is our component with the most issues, because it’s behavior is influenced by changes in Outlook and in all other COM-Add-ins you may have installed.
Why do you have “Send OpenPGP mail without attachment as PGP/inline” set? This option should usually not be used, PGP/inline is deprecated.
Another thing I notice is that you say it gets worse when you set “Resolve recipient keys automatically”. I guess that here the reply time of the configured servers could maybe be an issue.
Do your hangs maybe only occur when not all of the recipients certificates are already in your certificate list?
Why do you have “Send OpenPGP mail without attachment as PGP/inline” set? This option should usually not be used, PGP/inline is deprecated.
Of course I know it’s NOT safe to send with a plain of text….. But just for a test only and I want to know more about the issue (what aspects)….ect in details.
BTW: Maybe next time you can add a red warning beside the choice: (Not recommanded or Deprecated)
In order to simplify the issue, I just did an experienment by sending the letter to myself with the same email (Only one email), this also happens.
No problem, I think I can wait for your answer to solve it totally 
I’m now using Office 2024, Here’s the Outlook add-in: I didn’t install any other Add-ins, these are system-based after installation of Office 2024.
I looked at the logfile searching for gaps in the timestamps to see where it spends the time.
at line 3893 in thread 8288 it enters get_tmp_outfile at 13:20:36
at line 3910 it returns from the function at 13:50:38
Thats 30 mins !
Below the lines from the log from the main thread:
13:20:36/8288/TRACE/common.cpp:get_tmp_outfile:578 enter
13:20:36/8288/common.cpp:getTmpPathUtf8:559 char utf8 alloc 000002836e1340d0:C:\Users\ADMINI~1\AppData\Local\Temp
13:20:36/8288/w32-gettext.cpp:wchar_to_utf8_string:1540 char utf8 alloc 000002836e10f6b0:gpgol_enc.dat
13:48:45/8288/w32-gettext.cpp:wchar_to_utf8_string:1540 char utf8 alloc 000002836e10f030:gpgol_enc.dat
13:48:56/8288/common.cpp:get_tmp_outfile:common.cpp:get_tmp_outfile: Extension found .dat
13:48:56/8288/common.cpp:get_tmp_outfile:common.cpp:get_tmp_outfile: MAX_PATH check passed 50 <= 259
13:48:56/8288/DBG_DATA/common.cpp:get_tmp_outfile: Attachment candidate is C:\Users\ADMINI~1\AppData\Local\Temp\gpgol_enc.dat
13:48:57/8288/common.cpp:CreateFileUtf8:501 wchar_t alloc 000002836e19ba60:C:\Users\ADMINI~1\AppData\Local\Temp\gpgol_enc.dat
13:50:38/8288/TRACE/common.cpp:get_tmp_outfile:755: return
Looking further we see calls to wchar_to_utf8_string with 28 Mins difference
and the CreateFileUTF8 call also need 2 min
The code doesn’t do nothing fancy but does allocate memory in both calls
auto utf8Name = sanitizeFileName(wchar_to_utf8_string (name));
auto fileExtension = wchar_to_utf8_string (name);
Is that system memory constraint or otherwise bussy at least from the logs it looks like it.
I didn’t take a look at your source code, but if there’s something to do with std:wstring_convert, or something related it the char convert, maybe you should avoid doing it
std::wstring_convertis now abandonedsince C++17 by marking a deprecated label, because there's something issue in the compatible with some platforms of windows,Linux for some unknown issues, and it will no longer be used in the future, and it will be totally removed from C++ 20.
For more, you can see:
1、https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2872r0.pdf
2、cpp - C++ Character Encoding: Why You Shouldn’t Use std::wstring_convert
Maybe Boost.Locale is your choice, with a very fast speed.
No it’s not related to any std::string stuff.
It calls Windows WideCharToMultiByte to get the required buffersize, then mallocs a buffer and then WideCharToMultiByte again with the buffer to do the conversion.
sanitizeFileName does use some basic std::string stuff (erase, find, remove, regex_match, strlen) but on a 13 char long string those shouldn’t take a second or worse minutes.
Also later in the log (line 3920) get_oom_object call takes nearly a minute while all the other calls for that object later like on line 3970 return within the same second.
So the question is what is slowing the PC down so much.
Is it related to memory size? 4GB.
Nothing is allowed to install into the PC, so it’s clean after a pure Windows 11 loT with Office
