[Autogenerated] as we've seen the virtual APIs working page granularity,
which is good in many cases, but in some other cases this is not ideal,
these sizes perhaps are too big.
This is where the heap manager comes in.
The heat manager is the one managing the smaller locations it
knows for every allocation which one is allocated,
which is free.
And every time you ask the heat to provide another allocation,
finds a big enough chunk for you to use and manages all these things in
efficient enough way to help you work with these allocations without
having to utilize the mutual APIs directly.
The hip something functions as we'll see are the ones that are being
used in the windows Api These are documented in fact,
a very thin wrapper over the native apis in anti DLL which have the
name RTL something heap like RTL allocate hip.
And by the way,
they're also implemented within the kernel because kernel drivers in the
kernel itself also need access to small location allocations and it's not
always convenient to work with big chunks.
What kind of hips do we have?
So first there's always one process.
So first there's always one hip in a newly created process
called different process hip it is created by anti DLL and
there's always a handle,
you can get to that using the get process hip API it's
also not possible to destroy the hip.
So even if you don't do anything,
there's a hip they're already ready for for use,
you can create other hips if you so desire using the hip create API you
might be wondering why would you want to do that?
So here are a few ideas.
One problem with the hip or at least potential problem
with the hip is hip fragmentation.
If you have many small allocations of different sizes,
if you allocate and reallocate many of these chunks,
you might find that when you try to allocate,
for example, a 16 byte blocks in a block,
which is 20 bytes in size,
You're going to get those 16 bytes but then there will be these
four bytes left that no other allocation can feel.
So you get these small holes, so to speak in the address space and with time,
if the process running for minutes hours depending on what it's actually doing,
you might end up consuming more and more memory in
some cases for 32-bit processes,
you might even exhaust your address space and crush the process.
And so if you create your own heap, for example,
for allocating chunks of memory which always have the same size,
you'll have zero fragmentation there.
Another idea perhaps is the fact that the default
process hip has this lock around it.
So every time you have access from multiple threats,
there is a lot critical section being used behind the scenes in
order to make sure that the hip data structures and the metadata it
manages is not going to get corrupted.
So this is necessary.
On the other hand,
you might think maybe I want to make some allocations without any kind
of contention with the normal hip that is also used by various
existing APIs So you can create your own hip,
you can even specify that you don't want any kind of synchronization over
that hip if you're doing your own synchronization or just simply always
accessing the the hip with a single threat.
And so another motivation for creating a hip is exactly
that to try to relieve contention.
If multi threading is used a lot in the process in general,
any hip can be fixed in size or global, the default process,
hip is always global,
so you can grow for as much as the address space would allow
when you create a new hip using the hip,
create API you can either create a hip as global or make it
make it a fixed size if this is what you want,
so that it can't grow beyond that size.
If you try to allocate more, you'll start to get allocation failures.
Another thing that the heap manager provides is a layer,
code low fragmentation, heap, which is turned on by default.
When the heap manager thinks it's a good idea to do so in order to
reduce memory fragmentation I mentioned earlier,
the way this works is that every allocation that you're doing is
going to be rounded up to a certain set of sizes,
such as 16 bytes, 20 Before by 32 Bytes,
48 bytes and some other sizes and so when you free one of these chunks,
there's more likelihood for new chunks to be able to fit into that hole.
And so the downside is that you might consume a bit more memory but
you have a better chance of reduce fragmentation.
So this is a nice thing provided automatically by the heat manager in
Windows eight Microsoft created another new different implementation
for the heap called the segment hip.
And the segment hip has a bunch of advantages.
For example, it has a better block management scheme,
it's more secure because the metadata is stored away from the actual blocks.
So shell code that might have injected itself into the
process somehow would have a much more difficult time
trying to enumerate blocks on the hip.
However,
it is only used by UWP processes by default and
some system processes such as C S, r s S S S s services dot txt,
which is a service manager and a few other others.
The reason has to do with the fact that Microsoft tries to make sure
Windows is as compatible to previous versions as possible.
So for example,
suppose you have an application using the classic anti heap
implementation and everything looks fine and then if Microsoft
suddenly changes the implementation for that process,
it might surface bugs that weren't showing themselves in the
classic anti implementations Microsoft can't really take that risk
if you do want to use the segment heap, there are some values you can write,
in fact, a particular value.
You can write in the image file, execution options,
key,
the sound you are probably familiar with in order to
opt in into using the segment hip.
Otherwise,
you will only get the classic anti heap unless you're writing UWP application,
the Universal Windows platform applications,
you can upload to the Microsoft store.
They're relatively new, so they always use the segment heap.