|
From: Harald O. <har...@el...> - 2025-12-05 09:55:36
|
Dear Jan, dear Ashok, thanks for the debate. I appreciate all moves here. I personally have a lot of experiences with Windows and internal changes between minor releases, mostly be security issues. An example is the DLL load by .net, which suddenly did not work after a security patch, if the "from internet" flag was set to the dll. I searched one week for the reason. And it only showed up on client side, as they have received the dll by a download from our web-site. The dll load mechanism was often hit by security issues and is constantly changing. Perhaps, the "copy to temp and execute" will not be possible any more in future. It might be prohibitted to store dlls in the temp folder. Or only "installed" DLLs may be executed. It might happen, that DLLs have to reside outside of the executable and be correctly installed in future. I can understand that. Due to that, the "memory execution" was neat avoiding this issue. So, it is a decision between two alternatives with issues. We need reliabillity and I am ready to sacrifice a neat feature for it. The post by Ashok convinced me, that the risk of memory module in the core is to high. Due to that, please allow me to vote "No" on TIP 709. Thanks for your understanding, Harald |