Date: Fri, 17 Feb 2023 04:02:37 -0500
So what's the decision on this? Toss it under the carpet again or bring
forth a fix?
I think this needs to be fixed as the Windows memory manager really is
problematic.
Any changes we apply to C++ can easily be imported into Carbon later as
well.
On 2/16/23 15:07, Phil Bouchard via Std-Proposals wrote:
> So the other solutions would be to:
>
> On 2/12/23 09:55, Phil Bouchard via Std-Proposals wrote:
>> 1) Let's suppose we have all these new standards already in place then
>> it would be possible for an app to redirect low-level calls to
>> RtlAllocateHeap() and RtlFreeHeap() to some other custom defined using
>> another local hash table to redirect these calls.
>>
>> 2) Another solution would be to get Microsoft and other vendors to
>> call another handler using a function similar to set_new_handler.
>>
>> 3) Use something similar to LD_PRELOAD under Linux (or AppInit_DLLs
>> under Windows but deactivated under secure boot).
>>
>> Either option 1) or 2), vendors will have to modify their core
>> dynamics libraries. That is why I'm addressing this group.
>>
>> If you search engine search on Rtl*Heap() functions then this problem
>> lasted for a long time and all related bug reports were simply
>> dismissed. I think it's time to turn the page on those issues.
>
> 4) Again to implement virtual tables that would redirect allocation
> calls to any user-defined memory manager;
>
> 5) To standardize processes not sharing the same heap:
> https://www.boost.org/doc/libs/1_70_0/doc/html/process.html
>
>
forth a fix?
I think this needs to be fixed as the Windows memory manager really is
problematic.
Any changes we apply to C++ can easily be imported into Carbon later as
well.
On 2/16/23 15:07, Phil Bouchard via Std-Proposals wrote:
> So the other solutions would be to:
>
> On 2/12/23 09:55, Phil Bouchard via Std-Proposals wrote:
>> 1) Let's suppose we have all these new standards already in place then
>> it would be possible for an app to redirect low-level calls to
>> RtlAllocateHeap() and RtlFreeHeap() to some other custom defined using
>> another local hash table to redirect these calls.
>>
>> 2) Another solution would be to get Microsoft and other vendors to
>> call another handler using a function similar to set_new_handler.
>>
>> 3) Use something similar to LD_PRELOAD under Linux (or AppInit_DLLs
>> under Windows but deactivated under secure boot).
>>
>> Either option 1) or 2), vendors will have to modify their core
>> dynamics libraries. That is why I'm addressing this group.
>>
>> If you search engine search on Rtl*Heap() functions then this problem
>> lasted for a long time and all related bug reports were simply
>> dismissed. I think it's time to turn the page on those issues.
>
> 4) Again to implement virtual tables that would redirect allocation
> calls to any user-defined memory manager;
>
> 5) To standardize processes not sharing the same heap:
> https://www.boost.org/doc/libs/1_70_0/doc/html/process.html
>
>
-- Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> CTO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2023-02-17 09:02:39