Hi I have a buffer string

PostDataBuffer db 700 dup (?)

I'm using in an asm CGI, what I'd like to know how to do is
some how just declare a string of unknown length
then get my html form input, now I have a buffer string,
From there I use it, Parse it and catenate it to a structure, I got that done,
And then when I'm done with the buffer string, remove it from memory

in non code:

declare dynamic string
fill it with data
use it
get rid of it

Thanks Andy
Posted on 2002-03-15 11:29:35 by andy981
This involves using memory pointers and memory allocation.

1. Determine size of buffer needed
2. Allocate memory of size: HeapAlloc
3. Save pointer: (mov pointer, eax)
4. Fill Buffer (pointer)
5. Manipulate buffer (pointer)
6. Output buffer (pointer)
7. Free allocated buffer (HeapFree, pointer)

.data
pointer dd ?

Posted on 2002-03-15 12:04:03 by bitRAKE
Use Heap function, for instance
HeapCreate->HeapAlloc->HeapRealloc->HeapFree(HeapDestroy)
After HeapAlloc you get the pointer of specified data buffer

or if estimated size will more than 1Mb you can use VirtualAlloc
Posted on 2002-03-15 12:08:38 by masquer
andy981,

Windows already has support for dynamic strings in the OLE string memory pool.

SysAllocStringByteLen
SysFreeString
SysReAllocStringLen

They manage BSTR type string data and are very fast and convenient to use for what you are doing.

I have the help file as OLE.HLP from an old Borland C++ package and its about 2.7 meg.

Regards,

hutch@movsd.com
Posted on 2002-03-15 19:36:00 by hutch--
To use OLE strings, you have to bring in yet another DLL in your
app. Heap* functions are in kernel32, which you always need to
load anyway.

Oh well, whatever floats your boat.
Posted on 2002-03-15 19:40:14 by f0dder
I'm from the same point of view as f0dder here... I never saw the point to use OLE string memory functions...
Is there any advantage to use them ?

Thanks.
Posted on 2002-03-15 19:46:45 by JCP
Yes,

Its preallocated memory so its fast, its 16 BYTE aligned and its dynamically resizable with existing content. Its made to do the job and its a lot more memory efficient that system paging because its capable of handling from very small strings to very large ones.

Regards,

hutch@movsd.com
Posted on 2002-03-15 19:55:31 by hutch--
Hutch says they guarantee 32byte alignment (heap* only seems
to give you 8byte - you can make your own alignment logic pretty
easily if you need it, though).

My concern is how much overhead is brought in when you link to
oleaut32.dll . Sure, only used parts of the (613kb) oleaut32.dll are
paged in (unless some dweeb has compressed it), but *how much*
is used even though you only use the string funcs? Oleaut32.dll
also yanks in ole32.dll, advapi32.dll, gdi32.dll, user32.dll ... which
you might not need.
Posted on 2002-03-15 19:57:29 by f0dder

Its preallocated memory so its fast,

Preallocated? I don't assume any memory is allocted before you actually
call the SysAllocString* functions? :D


its 16 BYTE aligned and its dynamically resizable with existing content.

Alignment is nice, but can be handled with other routines easily. Most
memory allocation functions can be resized, the exception being VirtualAlloc :(.


Its made to do the job and its a lot more memory efficient that system paging because its capable of handling from very small strings to very large ones.

Correct me if I'm wrong, but I don't believe you can get away with paged
memory unless you're writing a ring0 driver. If you want to make sure
memory is paged in for other functions, simply touch the memory in page
increments.

Hopla, no need to bring in a crapload of DLLs unless otherwise needed :).
Posted on 2002-03-15 20:02:29 by f0dder
===============
Preallocated? I don't assume any memory is allocted before you actually call the SysAllocString* functions? :D
===============

You have assumed wrong. OLE string support is built into the system, UNICODE relies on it and the capacity to dynamically handle strings ranging from a few bytes to hundreds of megabytes is part of its capacity. It is the dynamic allocation that makes it far more efficient that manually alocated methods. Simple rule, never use more memory than you need.

Ther is no point in trying to strip the OLE support from the operating system, its there to be used and alternative methods of string handling are clunky in comparison.

=====================
Hopla, no need to bring in a crapload of DLLs unless otherwise needed
=====================

Too late, its already there.

=====================
Correct me if I'm wrong, but I don't believe you can get away with paged memory unless you're writing a ring0 driver.
=====================

Memory Mapped Files are supported by the system paging memory. Virtues = fast and accessible from other apps that map the view of the memory.
Vices = page granularity of 4k. Same with VirtualAlloc.

The older GlobalAlloc() will handle small allocations without the 4k page size granularity.

Allocate 500 seperate strings and do your arithmetic, 500 x 4k is 2000k. Do this with OLE string and you have used the amount of memory you have allocated in BYTE length, 500 strings at 16 bytes each or varying from 1 byte to whatever length is far more efficient than 4k page granularity and you don't have to create a seperate buffer during the resizing of the string.

Have PHUN.

hutch@movsd.com
Posted on 2002-03-15 20:09:15 by hutch--
Thanks Everyone

I used

mov bLen, eax
push eax
invoke SysAllocStringByteLen,0,bLen
mov hMem,eax
pop eax

Where addr Buffer would have been I used hMem instead

then freed the memory like this

invoke SysFreeString,hMem

I should have remember this, from my work with Hutch's Quick sort, routines I used in C with ASM demostration a few months ago

Thanks every one!
:)
Posted on 2002-03-15 22:58:44 by andy981
Hutch, I think you misunderstood me (and I misunderstood you,
probably because of difference in terms). Also, my text should have
been "Correct me if I'm wrong, but I don't believe you can get
non-pageable memory unless you're writing a ring0 driver." What
I mean is, all the available ring3 memory functions allocate memory
that can be paged out by the VM subsystem - I weren't talking about
page granularity (which would be insane for small string allocations,
unless you handle your own suballocations inside the page-aligned
memory).

And btw, no point in using local/globalalloc, they are wrappers
around Heap* functions.

Oh and btw, memory mapped files aren't fast, as they create
pagefaults on first page access per page :).
Posted on 2002-03-16 05:22:22 by f0dder