I have put considerable work over the last week to develop a new OOP library structure, and here is the first Class library I have finished to make life with MASM simpler.

Not only have i provided the Class file (CString.asm), but I have also provided a simple example showing 98% of the methods it offers. I hope you can appreciate the simplicity it offers for programming in MASM. As well there is full documentation of the library in HTML format.

Check it out and give me you your thoughts, concerns, or ideas for other Classes like this.

Enjoy!
:alright:
NaN
Posted on 2003-07-17 23:57:09 by NaN
Looks great at a first glance NaN, one extremely minor point (hardly worth mentioning), the CString.asm file has only line feeds no <CR>, makes for a single very long line in most editors. You can use wordpad to resave it with <CR>'s inserted.
Posted on 2003-07-18 00:16:08 by donkey
Dah! I thought i was past that problem.. Its like a virus, and UltraEdit preserves it, silently behind the scenes. I will convert them to standard DOS line feeds.

Thanks for pointing this out!
:NaN:

Its fixed now...
Posted on 2003-07-18 00:18:50 by NaN
Great NAN!

This helps out alot.
Look forward to your next projects!


:)
Posted on 2003-07-18 06:19:15 by packetvb
I dont really know what will be next. I was kinda hoping people would have ideas to discuss...
Posted on 2003-07-18 17:05:44 by NaN
Hehe, prolly because it's so close to perfection.
Thanks for sharing, this makes things a lot easier :)
Posted on 2003-07-19 12:09:07 by Ghirai
No problem, i will be releasing another 'version' of the CString class. I discovered out of necessity that it would be great to also have a method that will allow programmers create dynamicly sized buffers out of it.

API's like GetWindowText require a length and a string pointer. It would be good to do something like "CString.MakeBuffer, UserInputedLenght" and have it return in eax the address to a buffer of what ever the length is at run time.

Currently you probably most often use the stack for buffers, which require you to know ahead of time the maximum size of the buffer. But for things like strings, you may not know the length until run time. This is where such a method would be better tailored, since you dont have to impose restrictions on the program's use.. (ie. dont exceed 256 chars in the edit field of this dialog box).

:NaN:
Posted on 2003-07-19 16:13:27 by NaN
I really like to have Insert,Delete,PatternMatch(like PathMatchSpec functio?n in shlwapi.dll) function in this class.Keep up the good work:alright:
Posted on 2003-07-20 06:45:05 by LaptoniC
You really need an insert function? You can do it like so...:


mov hNew, $EAX( hString. CString.Left, InsertPoint )
MEHTOD hNew, CString.CatString, szInsertStringPointer
mov hRight, $EAX( hString. CString.Right, InsertPoint )
METHOD hNew, CString.CatString, $EAX(hRight, CString.GetAddr )
METHOD hString, CString.UpdateString, $EAX( hNew, CString.GetAddr )
DESTROY hRight
DESTROY hNew


Likewise to delete a section can be done:


mov hNew, $EAX( hString. CString.Left, DelStart )
mov hRight, $EAX( hString. CString.Right, DelEnd )
METHOD hNew, CString.CatString, $EAX(hRight, CString.GetAddr )
METHOD hString, CString.UpdateString, $EAX( hNew, CString.GetAddr )
DESTROY hRight
DESTROY hNew


I think your Path concern might be valid tho.... What are your thoughts? Is this too much source to do on your own with the class?? Maybe im wrong here?

At anyrate thanks for the suggestion! :alright:
:NaN
Posted on 2003-07-20 13:27:28 by NaN
Hi NaN,

the first example I executed was CatString.exe and ........ it didn't work! Isn't this lib supposed to make our life easier? :)

I built a debug version of this example and ... it worked! Very strange.

Looking at the source:



CStr_CatString_Funct PROC uses edi esi ebx lpTHIS:DWORD, lpsz:DWORD
SetObject edi, CString

mov ebx, [edi].szLength
.if( ebx )
.if( lpsz )
xor esi, esi
mov esi, $invoke( StrLen, lpsz )
.if( esi )
add ebx, esi
add ebx, 4
invoke GetProcessHeap
invoke HeapReAlloc, eax, HEAP_ZERO_MEMORY, [edi].pStrMem, ebx
.if( eax )
invoke szCatStr, eax, lpsz
invoke StrLen, [edi].pStrMem
mov [edi].szLength, eax
.else
xor eax, eax
.endif
.else
xor eax, eax
.endif
.else


My guess is that you expect the memory pointer returned by HeapReAlloc to be the same as the one you supplied as parameter. Thats not true.

Japheth
Posted on 2003-07-27 08:17:34 by japheth
Yes. This exactly what i expect. And is what happens on my OS Win98SE.

I f'n hate M$ and their vague a$$ B.S. when i comes to describing certain api's. I specifically checked for this before i used the API and it gave me nothing to work with. So i did tests and found it *did* return the same pointer on my machine. Every time!. This is all the API had to say
The HeapReAlloc function reallocates a block of memory from a heap. This function enables you to resize a memory block and change other memory block properties. The allocated memory is not movable.

Return Value

If the function succeeds, the return value is a pointer to the reallocated memory block.
If the function fails and you have not specified HEAP_GENERATE_EXCEPTIONS, the return value is NULL.
If the function fails and you have specified HEAP_GENERATE_EXCEPTIONS, the function may generate the following exceptions:

Remarks

If HeapReAlloc succeeds, it allocates at least the amount of memory requested. If the actual amount allocated is greater than the amount requested, the process can use the entire amount. To determine the actual size of the reallocated block, use the HeapSize function.
To free a block of memory allocated by HeapReAlloc, use the HeapFree function.


Can others Test this example on your machines and tell me what your machine is, and what the result was (worked or didnt). Thanks!

As well i will redesign this section to avoid using M$'s api in this case. And post it soon.

:NaN:
Posted on 2003-07-27 11:23:16 by NaN
Hi NaN

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
As well i will redesign this section to avoid using M$'s api in this case. And post it soon.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Dont exaggerate it. I would suggest just to save the new pointer in .pStrMem.

If you think about the structure of a heap you may recognize that it is impossible to enlarge a memory block and keep its address in all cases. So it is quite normal in my eyes that address may change. You can avoid this change by setting flag HEAP_REALLOC_IN_PLACE_ONLY, but this surely wouldnt improve things.

Japheth
Posted on 2003-07-27 15:43:35 by japheth