Hey,

I was just wondering, what is faster and/or smaller code ? Using the strings functions like lstrcat, lstrcpy, etc etc or writting my own code to preform the same task ?? For example:



INVOKE lstrcpy, ADDR strTest1, ADDR strBuffer


or ...



MOV EDI, OFFSET strBuffer
MOV ESI, OFFSET strTest1
MOV ECX, SIZEOF strTest1 ; Is this a good thing to do ?
REP MOVSB


The reason I ask, is because, I want to learn as much of Assembler as humanly possible, but I don't want to use other peoples code (the string functions i mentioned for example) when I can write my own assembly code that can do the same job !! But am not sure which is faster, better, more professional ??

Thanks in advance
Posted on 2002-09-13 07:19:56 by Dracton
I think that SIZEOF will return a 4 for a DWORD. So to find the length og the string, I would scan the addresss until a reach a zero, dont worry about spaces, spaces are 20h, so when u encounter a 0 you'll know thats the end of the string!
Posted on 2002-09-13 07:23:05 by x86asm
Thanks,

Yeah, I know that, but why shouldn't I use SIZEOF and why should I write assembler code to search for the end of string, if I can just use the SIZEOF method ?
Posted on 2002-09-13 07:27:22 by Dracton
Dracton....

Thes SIZEOF will NOT return the size of a null terminated string... that can and will change at runtime so sizeof can not guess it...

It will only return the size of an structure definition or tyupedefs or simple variables
Posted on 2002-09-13 07:37:36 by BogdanOntanu
Dracton,
the general opinion on the board is that if you write it yourself you can probably make it faster than the APIs included with windows. At least, I have yet to see a string operation in windows that has stood up against members on the board writing their own code.

Will it be smaller? Well, not really because you get APIs for "free". That is, the API does not add any size to your executable (except the actual invoke of course)

If you want to improve your ASM skills, writing functions like this will certainly help a lot. Or look through some of the threads on string functions (there are several). You can learn a lot about optimizing code and writing for different processors (as this can greatly affect the speed of your code)

--Chorus
Posted on 2002-09-13 11:11:28 by chorus
Righty oh,

Best get to work making that custom lstrlen function then :)
Posted on 2002-09-14 06:24:14 by Dracton

Will it be smaller? Well, not really because you get APIs for "free". That is, the API does not add any size to your executable (except the actual invoke of course)
Very small examples. ;)
Posted on 2002-09-14 09:27:35 by bitRAKE
lstrcpy is not Part of the Win32 API. It's a library. Same with StrLen.
Posted on 2002-09-16 23:08:44 by eet_1024
lstrcpy is not Part of the Win32 API.


Really? But my kernel32.dll tells me it exports: :)
lstrcpy
lstrcpyA
lstrcpyW
lstrcpyn
lstrcpynA
lstrcpynW
Posted on 2002-09-17 03:52:11 by Four-F
Indeed it is apart of the kernell .... because also get the same result Four-F got when you look "into" the DLL.
Posted on 2002-09-19 06:20:54 by Dracton
My bad. Was thinking of CopyMemory.

If those really exists, why is StrLen constantly being reinvented (excluding the convieniance of ecx)?
Posted on 2002-09-22 04:18:35 by eet_1024

If those really exists, why is StrLen constantly being reinvented (excluding the convieniance of ecx)?
Because the string length code can be smaller, or faster than the API. :)


; string length
mov edi,_T("Just a simple test...")
mov al,0
or ecx,-1
repne scasb
not ecx
dec ecx
Posted on 2002-09-22 04:28:31 by bitRAKE