Asm++,

Yeah, you're kind of right about this. But if StringCopy is MemoryCopy (saved as RtlMoveMemory in ntdll.dll), you can also say, that StringLen is like a lstrlen or strlen from WinAPI. And it'll the true. So why should you use one of my functions? Just run Cheat Engine or similar tool, and research Microsoft's procedures. They're much larger and slower. It's everything what I can say about this.

Buffer rb 256
sHello db 'HELLO',0
...
invoke lstrcpyA, Buffer, sHello
;
; Then here you call a replacement function, so there will
; be enough room in 'Buffer'.
;
stdcall StringReplace, ...
    

Well, it depends on your goal - size vs. speed.

But, assuming we follow the windows/x86 register preservation rules and C calling convention, can we do a strcpy-that-relies-on-calling-strlen shorter than this?

Code:

strcpy:; 24 bytes
        push    esi
        push    edi

        mov     edi, [esp + 12] ; dst
        mov     esi, [esp + 16] ; src
        
        push    esi
        call    strlen
        mov     ecx, eax
        rep     movsb
        
        pop     eax ; to get rid of arg for strlen
        pop     edi
        pop     esi
        ret    

Here's a couple of straightforward alternatives that don't rely on first calling strlen:

Code:

strcpy_1:       ; 19 bytes
        push    esi
        push    edi
        mov     edi, [esp + 12] ; dst
        mov     esi, [esp + 18] ; src
.copy:
        lodsb
        stosb
        test    al, al
        jnz     .copy

        pop     edi
        pop     esi
        ret

strcpy_2:       ; 19 bytes
        mov     edx, [esp + 4]  ; dst
        mov     ecx, [esp + 8]  ; src
.copy:
        mov     al, [ecx]
        mov     [edx], al
        inc     ecx
        inc     edx
        test    al, al
        jnz     .copy
        ret    

Not claiming any of those are optimal (or even good, and they haven't been tested - they're just food for thought.

This topic grew fast!
Looks like string functions is a pain for coders.

Lets talk more about replacement.
Of course, when I said about allocations -- I meant that the programmer
must ensure that there is room in a string buffer to do a replacement.

Something like this:

Code:

Buffer rb 256
sHello db 'HELLO',0
...
invoke lstrcpyA, Buffer, sHello
;
; Then here you call a replacement function, so there will
; be enough room in 'Buffer'.
;
stdcall StringReplace, ...
    

Other possibility is to create an object which is a string and it makes sure
that the room is always there and if not -- expands the buffer by reallocation.
But doing that will involve a lot of effort. Writing the allocator for it and
doing all the functions, like concatenation, insert, remove, searching of character and string and other stuff -- a full library.

Looks like string functions is a pain for coders.

Did not tested your code yet but, I am curious, how did you calculated the size of it?
If I'm not wrong, the first one is 30 bytes, the second and the third are 27 bytes!

Quote:

That's pretty simple - fasm

In other words: You can count yourself. If you aren't lazy, of course.

This topic grew fast!

mov edi,pString
mov al,0
mov ecx,-1
repne scasb    

align 32
TString_Length:
; ---------------------------------------------------------------------------
; INPUT:
;   EDI = ANSI text (zero-byte terminated)
; OUTPUT:
;   ECX = text length (not including zero terminator)
; ---------------------------------------------------------------------------
    push      eax edi
    or        ecx, -1
    xor       eax, eax
    repne     scasb
    not       ecx
    dec       ecx
    pop       edi eax
    ret
    

Quote:

That's pretty simple - fasm

In other words: You can count yourself. If you aren't lazy, of course.

"Several times"? Methink, "several orders of magnitude" will fit better.

Why FASM did not use 32-bit as a default option rather than 16-bit?

strlen_1:       ; 17 bytes
        mov             eax, [esp + 4]
.scan:
        inc             eax
        cmp             byte [eax-1], 0
        jne             .scan
        
        sub             eax, [esp + 4]
        dec             eax
        ret

strlen_2:       ; 15 bytes
        mov             ecx, [esp + 4]
        xor             eax, eax
        dec             eax
.scan:
        inc             eax
        cmp             byte [ecx + eax], 0
        jne             .scan
        ret

strlen_3:       ; 20 bytes
        push    edi
        mov             edi, [esp + 8]
        xor             ecx, ecx
        not             ecx
        xor             al, al
        repne   scasb
        not             ecx
        lea             eax, [ecx - 1]
        pop             edi
        ret    

Probably because it's the starting mode for x86 processors? And because one of the most widespread uses for binary output was .com files?

I added a couple of strlen routines in the zip above, might as well post them inline as well

Asm++ wrote:

I think there are other important things to invest man's time rather than the sitting down and counting the bytes!

That is important, a wrong calculation can lead to bugs, crashes, exceptions and others (if any).

The time is mine, let me spend it the way I want to. You people just keeps caring about useless details (such as license change) and now you throw stones at me for this (detail).

I can't understand.

f0dder wrote:

Probably because it's the starting mode for x86 processors? And because one of the most widespread uses for binary output was .com files?

Yes, may be, but I think it should be changed, as we no longer in Dos era.

; format PE GUI 4.0

include "win32ax.inc"

macro showhex caption,value {
        local .over,.str
        jmp     .over
        .str    db caption," = %08Xh",0
 .over: pushad
        mov     ebx,value
        stdcall [GlobalAlloc],GMEM_MOVEABLE+GMEM_ZEROINIT,1000h
        push    eax
        push    eax
        stdcall [GlobalLock],eax
        push    eax
        ccall   [wsprintf],eax,.str,ebx
        pop     eax
        stdcall [MessageBox],0,eax,0,MB_OK+MB_ICONASTERISK+MB_APPLMODAL
        call    [GlobalUnlock]
        call    [GlobalFree]
        popad
}

macro sra {
        showhex 'eax',eax
}

macro srb {
        showhex 'ebx',ebx
}

macro src {
        showhex 'ecx',ecx
}

macro srd {
        showhex 'edx',edx
}

macro sredi {
        showhex 'edi',edi
}

macro sresi {
        showhex 'esi',esi
}

.data
        source db "This is a kind of text. This kind is a big fat kind",0
        search db "kind",0
        search2 db 'is a', 0
        replace db "line",0
        dest dd ?

.code
main:
        invoke MessageBox, 0, source, "", 0

        stdcall StringSearch, source, search, 1
        sra
        srb

        stdcall StringSearch, source, search2, 1
        sra
        srb

ret

proc StringSearch uses ecx edx esi edi, Buffer, Find, First

    local NextBytePos dd ?

        cmp byte[First],1
        jne @F
        mov [NextBytePos], -1
        @@:
        mov esi, [Buffer]
        mov edi, [Find]
        mov eax, 0
        mov edx, -1
        mov ecx, [NextBytePos]

    .L0: inc ecx
        mov al,byte[esi+ecx]
        cmp al,0
        je .L9
        mov bl, byte[edi]
        cmp bl, 0
        je .L9

            .if al = bl
                cmp edx, -1
        jne @F
        mov edx,ecx
          @@:
                inc edi
        jmp .L0
            .elseif edx <> -1
                mov ecx,edx
        mov edx,-1
            .endif
            mov edi,[Find]
            jmp .L0

    .L9: .if bl = 0
            .if al <> 0
                mov eax, edx
        mov ebx, ecx
            .else
                mov eax, -1
            .endif
        .else
            mov eax, -1
        .endif

        mov [NextBytePos],ecx
       ret
endp

.end main