If I create a buffer in the data or data? section is there any way to get rid of of it when i no longer need it.
mega thanx
:alright:
mega thanx
:alright:
If you want to create a buffer and then delete it , you can allocate memory at runtime, use it and then dispose it.
For such task the *Alloc,*Free,*ReAlloc group of API will do it. (ie GlobalAlloc,GlobalFree,HeapAlloc,HeapFree,etc).
Iczelion's tutorial N? 12 explains the ins and outs of runtime memory allocation.
You will not be able to destroy buffers declared in the .data or .data? section.
What you could also do (depending on the case) is to use local buffers (as in procedures) which will be automatically destroyed when the procedure returns.
This are my two pence :)
Latigo
For such task the *Alloc,*Free,*ReAlloc group of API will do it. (ie GlobalAlloc,GlobalFree,HeapAlloc,HeapFree,etc).
Iczelion's tutorial N? 12 explains the ins and outs of runtime memory allocation.
You will not be able to destroy buffers declared in the .data or .data? section.
What you could also do (depending on the case) is to use local buffers (as in procedures) which will be automatically destroyed when the procedure returns.
This are my two pence :)
Latigo
Ya... As long as your not buffering a WAV or BITMAP data (ie, big buffers!), you can easily get away with using the LOCAL stack. I did a test a while ago to see how many DWORDS I could push on the stack, and the # was in the ten's of thousands before i got a GPF. (remember a dword == 4 bytes!, so the byte allowed is 4 times this!)
Format: LOCAL myArray[128] :BYTE
Its also best if you keep the allocated # of bytes in your array to multiples of 4, for allignment issuses ( a topic im not too well versed in, basically keeps code runing at its best ).
Hope this helps..
NaN
Format: LOCAL myArray[128] :BYTE
Its also best if you keep the allocated # of bytes in your array to multiples of 4, for allignment issuses ( a topic im not too well versed in, basically keeps code runing at its best ).
Hope this helps..
NaN
... and you can get away with even more than that. Just set the
linker options for stack commit and reserve size. Just a little problem...
because of the way the stack is grown using "guard pages", you must
access the data in a linear fashion, from start to end, otherwise
you can expect crashes... but that can be alleviated by "pretouching"
the memory.
linker options for stack commit and reserve size. Just a little problem...
because of the way the stack is grown using "guard pages", you must
access the data in a linear fashion, from start to end, otherwise
you can expect crashes... but that can be alleviated by "pretouching"
the memory.