Memory using API

[Polo]

I don't like PB Memory's function a lot, so I would like to use API's function to manage the memory. I have seen some api function which are equivalent to PB's one on this forum, but I don't remember where, does someone have them ?

[freedimension]

GlobalMemoryAlloc_
GlobalMemoryReAlloc_
GlobalMemoryFree_

to be found in the WinAPI.hlp or Windows PSDK

Also there is a Userlibrary somewhere that covers your request. Take a look at www.purearea.net

[freak]

Actually, the heap functions are equivalent to PB's memory functions:

HeapCreate_()
HeapAlloc_()
HeapReAlloc_()
HeapSize_()
HeapFree_()
HeapDestroy_()

they are faster than the Global memory functions.

Timo

[Danilo]

Code: Select all

;
; by Danilo, 12.12.2003 - english forum
;
#HEAP_ZERO_MEMORY = $00000008

Procedure.l malloc(size)
  ProcedureReturn HeapAlloc_(GetProcessHeap_(),#HEAP_ZERO_MEMORY,size)
EndProcedure

Procedure.l free(mem)
  ProcedureReturn HeapFree_(GetProcessHeap_(),0,mem)
EndProcedure

Procedure.l realloc(mem,new_size)
  ProcedureReturn HeapReAlloc_(GetProcessHeap_(),#HEAP_ZERO_MEMORY,mem,new_size)
EndProcedure

Procedure.l msize(mem)
  ProcedureReturn HeapSize_(GetProcessHeap_(),0,mem)
EndProcedure


mem = malloc(1000)
Debug "mem at  :"+StrU(mem,#LONG)
Debug "mem size:"+StrU(msize(mem),#LONG)
Debug "filling mem..."

*x.BYTE = mem
For a = 0 To 255
  *x\b = a
  *x+1
Next a

mem = realloc(mem,2000)
Debug "mem at  :"+StrU(mem,#LONG)
Debug "mem size:"+StrU(msize(mem),#LONG)

Delay(2000)

; old content is still there after re-allocation !!

*x = mem
For a = 0 To 255
  Debug Chr(*x\b&$FF)
  *x+1
Next a

; mem is automatically freed on program exit,
; but you can also free it with free()
free(mem)

[freedimension]

Actually, the heap functions are equivalent to PB's memory functions:

HeapCreate_()
HeapAlloc_()
HeapReAlloc_()
HeapSize_()
HeapFree_()
HeapDestroy_()

they are faster than the Global memory functions.

Timo

Yes, that's true. But I always wondered, how to predict the size of the heap? For my Opinion this is to rigid and static for real dynamic memory allocation. But I'm sure, I must have missed something in this context, so please give me a hint and convince me

[freak]

> But I'm sure, I must have missed something in this context, so please give me a hint and convince me

You just set 'dwMaximumSize' to 0 when creating the heap. This will create
a heap that can grow. See here:

If dwMaximumSize is zero, the heap is growable. The heap's size is limited only by available memory. Requests to allocate blocks larger than 0x7FFF8 bytes do not automatically fail; the system calls the VirtualAlloc function to obtain the memory needed for such large blocks. Applications that need to allocate large memory blocks should set dwMaximumSize to zero.

Timo

[freedimension]

> But I'm sure, I must have missed something in this context, so please give me a hint and convince me

You just set 'dwMaximumSize' to 0 when creating the heap. This will create
a heap that can grow. See here:

If dwMaximumSize is zero, the heap is growable. The heap's size is limited only by available memory. Requests to allocate blocks larger than 0x7FFF8 bytes do not automatically fail; the system calls the VirtualAlloc function to obtain the memory needed for such large blocks. Applications that need to allocate large memory blocks should set dwMaximumSize to zero.

Timo

Ah, I see. Very nice. Is PBs Heap also growable?

[freak]

I think yes.

I don't get the concept of a non growable heap anyway. They could
just all be growable, who needs a restricted one??

Timo

[Seldon]

@Freak:
>they are faster than the Global memory functions

I could be wrong... but I think all the Heap* functions are wrappers to Global* memory function on Windows9x/NT+. So there's no speed difference. The Heap* functions had a sense on Windows3.1 , but from Windows95, all applications have their own virtual memory address.

From the WinAPI help file about GlobalAlloc call:
The GlobalAlloc function allocates the specified number of bytes from the heap. In the linear Win32 API environment, there is no difference between the local heap and the global heap.

[El_Choni]

It's the other way round, the Global* functions wrap the Heap* functions and are mostly deprecated (there are very few situations left when you need to use Global*).

[freak]

El_Choni is right. This is what the PSDK says about GlobalAlloc_():

Note The global functions are slower than other memory management functions and do not provide as many features. Therefore, new applications should use the heap functions. However, the global functions are still used with DDE, the clipboard functions, and OLE data objects.

Timo

[inc.]

Sorry to bring this up but I do think it deserves to be posted in here ...


In a C function I got this 'GlobalAlloc' based Function

GlobalAllocPtr(GMEM_MOVEABLE | GMEM_SHARE, size)

in Windowsx.h the Macro 'GlobalAllocPtr(..)' is defined as followed:

#define GlobalAllocPtr(flags,cb) (GlobalLock(GlobalAlloc((flags), (cb))))

ElChoni says

It's the other way round, the Global* functions wrap the Heap* functions

So if I would need a pointer to an allocated Memory supporting GMEM_MOVEABLE,
how could that be done via 'HeapAlloc_()' or even more interesting how could this be archived with PBs 'AllocateMemory()'

Cause MSDN says

The HeapAlloc function allocates a block of memory from a heap. The allocated memory is not movable.

Purpose is to allocate memory for audiobuffer usage which will be refilled continously while played back. The C function above is from a sample M$ code for audiostreaming/playback.