Allocate Memory

[Force]

Is it possible to allocate memory without windows api in assembly ?

[jj2007]

StackBuffer, for example. But why do you want to avoid HeapAlloc?

[dedndave]

how much memory - and how long do you need it ?

there is also the uninitialized data section

Code Select Expand

    .DATA?

buffer db 16384 dup(?) ;16 KB buffer - lifetime of the process

[Force]

i found something in Fasm but i m not sure if it's possible in Masm32

Code Select Expand

macro allocMem var,nbytes
{
virtual at nbytes
var db nbytes dup (?)
  end virtual
}

Code Select Expand

allocMem buffer,70

[AssemblyChallenge]

I have a question too.

So far I have been using the .Data? section too for buffers and stuff without increasing the final exe's size. But, is there a limit on how much you should allocate by this method? How do you know memory APIs are mandatory instead of .Data?

Please.

[dedndave]

if it weren't for a MASM bug, you can go as far as address space will allow - assuming the user has memory
for XP, that would be almost 2 GB, including all your code and data

MASM has a bug that makes the assembler run slow for buffers above 64 KB

but - unless you need all that memory for the entire life of the process, it's not very responsible programming
in many cases, it is better to allocate memory, as needed - and release it when done

and - if you want to use 2 GB, and the user has 1 GB of RAM, the program won't load - lol

[Force]

i think Globalalloc is better 

[dedndave]

that depends on what your strategy is
you may want to use virtual memory - if you need more than available RAM
and - GlobalAlloc ends up calling HeapAlloc, as i recall
MS has depricated GlobalAlloc, except places where it must be used
the clipboard is one place that comes to mind
some streaming i/o also requires globally allocated memory

[rrr314159]

Random comments,

yes MASM32 has similar to FASM's macro allocmem. Look in MASM32/macros/macros.asm; macros called "literal", SADD and CADD.

GlobalAlloc is deprecated by MS; MS wants u to use HeapAlloc instead in most cases; it's a little quicker too. {NOTE, as I was typing this dedndave mentioned same thing; guess I'll leave it here, reinforce the point}. Works the same. But ANY alloc is very slow; definitely don't want it in inner loop. Still it can be more convenient than data?, particularly when you don't know how many blocks of mem will be used in the prog. Whenever you know initially how many blocks of mem u need, data? probably better.

The ML.exe bug, for data? above 64k, is still there in ML64 (big disappointment). However JWasm works right; allocates as much as 2 gig too quick to notice. JWasm does have a couple problems ML doesn't; but generally it's better, give it a try. True, it's not responsible programming to pre-allocate huge amounts of mem, but 64K is not huge; even a few megabytes is, really, nothing. So for smaller (up to 100 megs, say) amounts this is usually best.

Using the stack - up to 4K, no problem, but don't try to access it after u return from the proc that does the allocating.  Up to a megabyte or so should be possible but stack must be probed. MASMBasic's StackBuffer takes care of that; but when you use the mem sequentially pre-probing's not necessary, usually init not necessary either. For thread-safe, and for speed, this is (IMHO) the best way; but requires more than usual care.

So if you're using data? happily, you're all set. Otherwise u need either JWasm, HeapAlloc, or stack allocation, depending what the problem is.

WARNING: as a newbie, I don't really know what I'm talking about, so take it for what it's worth  :icon_cool:

[hutch--]

Uninitialised data is handy for variables that you need but it is fundamentally a poor technique for memory of any real size. Anything you add to the DATA? section stays there for the duration of the running app where dynamically allocated memory can be turned on and off.

RE: GlobalAlloc(), there is another term for deprecated, its "stable" which means Microsoft will not stuff it up any longer. Trace it through the guts of system DLLs and you will find it uses the same memory source as HeapAlloc() but is a bit simpler to use. This much, with any allocated memory, once it is allocated, its all the same speed. If you need many small allocations, do yourself a favour and allocate it all in one lump then chop it up to the sizes you need. It is trivial to align memory so if you can find a way to allocate it that works, you can do most anything you like with it as long as you stay within its range.

[Force]

Thanks for explaining Hutch !..

I just use GlobalAlloc in my programs but There are afew ways for allocation .... VirtualAlloc, HeapAlloc etc..

please someone can explain me, should i use others too ?  or are they for different memory (long or short)?

[dedndave]

HeapAlloc and GlobalAlloc are similar in many ways
they allocate memory from available RAM
HeapAlloc takes a little more work - you have to use CreateHeap or GetProcessHeap (easy way) to get a heap handle
GlobalAlloc may allocate moveable or non-moveable blocks - no heap handle required

VirtualAlloc will allocate from RAM when available
if not, it will use a cache file on the hard drive (or a combination of the 2)
therefore, you can allocate larger blocks, beyond what might be available

i often use the stack for temporary allocations
care must be taken so that you don't try to access uncommitted memory
this is done by probing the stack
in this post, and a few that follow, i show some examples

http://masm32.com/board/index.php?topic=3326.msg35046#msg35046

[Force]

Thank you Dave

I understand clearly  now :t

[MichaelW]

Using the stack - up to 4K, no problem, but don't try to access it after u return from the proc that does the allocating.  Up to a megabyte or so should be possible but stack must be probed. MASMBasic's StackBuffer takes care of that; but when you use the mem sequentially pre-probing's not necessary, usually init not necessary either. For thread-safe, and for speed, this is (IMHO) the best way; but requires more than usual care.

Or you can just use the linker /STACK:reserve[,commit] option to make the stack whatever size you need, and forget about the probing.

[Force]

Thanks rrr314159 and  Michael

Before starting to learn assembly programming ... anybody said that I can find any solution in assembly
Yes we can make every C functions in assembly except allocation memory. So i was finding out if it's possible in assembly.Other problem ... Even i write any  macro   i can't be sure if really memory is allocated or not. i test it with GlobalSize or HeapSize .... Result is always zero