Re: Avoid use deprecated Windows Memory API

Em qui., 15 de set. de 2022 às 10:30, Daniel Gustafsson <daniel(at)yesql(dot)se>
escreveu:

> > On 15 Sep 2022, at 15:13, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> wrote:
> >
> > On 2022-Sep-15, Ranier Vilela wrote:
> >
> >> Em qui., 15 de set. de 2022 às 09:50, Alvaro Herrera <
> >> alvherre(at)alvh(dot)no-ip(dot)org> escreveu:
> >
> >>> These functions you are patching are not in performance-sensitive code,
> >>> so I doubt this makes any difference performance wise. I doubt
> >>> Microsoft will ever remove these deprecated functions, given its
> history
> >>> of backwards compatibility, so from that perspective this change does
> >>> not achieve anything either.
> >>
> >> If users don't adapt to the new API, the old one will never really
> expire.
> >
> > If you are claiming that Microsoft will remove the old API because
> > Postgres stopped using it, ... sorry, no.
>
> Also, worth noting is that these functions aren't actually deprecated. The
> note in the docs state:
>
Daniel, I agree that MSDN could be better written.
See:
"Remarks

Windows memory management does not provide a separate local heap and global
heap. Therefore, the *LocalAlloc* and GlobalAlloc
<https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-globalalloc>
functions are essentially the same.

The movable-memory flags *LHND*, *LMEM_MOVABLE*, and *NONZEROLHND* add
unnecessary overhead and require locking to be used safely. They should be
avoided unless documentation specifically states that they should be used.

New applications should use the heap functions
<https://docs.microsoft.com/en-us/windows/desktop/Memory/heap-functions>"

Again, MSDN claims to use a new API.

And following the bouncing ball into the documentation they refer to [0] I
> read
> this:
>
> As a result, the global and local families of functions are
> equivalent
> and choosing between them is a matter of personal preference.
>
IMO, This part has nothing to do with it.

regards,
Ranier Vilela