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
That is the guess of @mmo and it’s a logical explanation. 4GB is not much for WIN11, though the requirements of their IoT version is probably less than the regular one.
I would monitor memory and load of your system and also which processes are running and might be problematic when the issue occurs.
Hey
I still have the same problem (cpu: i5-13500H + 32GB memory).
But searching for all the issues, I found：
Can u tell me how to set to “UTF-8”, maybe this is a solution…
Anyone here？What do u mean by “UTF-8” in settings? @eebb I met the same issue with a high performance of my PC.
Maybe you should re-consider supporting Non-Latin letters together as a common function for the next generation of GpgOL.
@mmo ：
I don’t think it a good idea if you use “std:string” to process with Non-Lartin letters, bcoz it copes with them “one by one” like what it does for ASCII letters. So if possible, maybe you can consider：
Hi @Susi, you can not set to UTF-8 in Gpg4win, this is a setting of your operating system. You’ll find instructions on the internet.
UTF-8 is the most widespread encoding and can encode non-latin characters, too. Encodings like Shift-JIS are no longer needed afaik and used by a minority only even in countries with CJK languages.
I’m using Windows 11, and I’ve set in the Region:
“Beta: Set All non-union characters to UTF-8”, checked and restart my PC.
But nope:(
Hi @Susi,
as your symptoms may be the same as the original poster’s, but the chance is high that your situation is quite different. (So often it is best to open a new discussion if the old one seems different, but now we are here, which is fine.)
Can you state the precise version of Windows, its language settings and the versions of Gpg4win and Outlook you are using?
Did you try to get a GpgOL log file?
