Page 1 of 1

Memory using API

Posted: Thu Jan 29, 2004 9:16 pm
by 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 ?

Posted: Thu Jan 29, 2004 10:38 pm
by 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

Posted: Thu Jan 29, 2004 10:51 pm
by 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

Posted: Fri Jan 30, 2004 7:49 am
by 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)

Posted: Fri Jan 30, 2004 11:31 am
by freedimension
freak wrote: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 ;-)

Posted: Fri Jan 30, 2004 11:45 am
by 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

Posted: Fri Jan 30, 2004 1:49 pm
by freedimension
freak wrote:> 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?

Posted: Fri Jan 30, 2004 2:04 pm
by 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

Posted: Sat Jan 31, 2004 9:54 am
by 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.

Posted: Sat Jan 31, 2004 12:41 pm
by 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*).

Posted: Sat Jan 31, 2004 2:11 pm
by 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

Posted: Thu Mar 02, 2006 1:37 pm
by 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.