well i have try unsuccesfuly to do this.... heres some code:

invoke lstrlen,addr passw ;get string lenth
mov lo,eax ;lo has total amount 
invoke Encrypt, addr passw, addr destin, lo ;call function
invoke MessageBox,hWnd,addr destin,NULL,MB_OK ;tell us what the string is backwards....
.
.
.
Encrypt proc source :DWORD, dest :DWORD, lo :DWORD
LOCAL lo2:DWORD

   mov ecx, source ;put address into ecx
@@:
    inc ecx ;increase the position in ecx
    dec lo  ;nock off a place
    inc lo2 ;set up secondary counter for latter
    cmp lo,0 ; are we done yet?
    jne @B ;if not jump back
    mov edx, dest   ;put address into edx
    
@@:
    mov al,    ;copy byte at address in ecx to al,should be at end of string...    
    dec ecx         ;decrease the position of ecx
    dec lo2         ;count down so we know when where done
    mov ,al    ;move what was in ecx into edx
    cmp lo2,0       ;are we done yet?
    jne @B          ;if not jump back
    
    ret

Encrypt endp

does this make any sence at all??? i keep getting an illegal operation when running it... any help would be apreciated. thanx. -brad
Posted on 2001-03-17 21:17:00 by Rage9
Did not try your code,but you are not initializing lo2, if this is not crashing, it will definitly give unpredictable results. The Following code will reverse a string for you.

ReverseStr proc uses edi esi Source:DWORD,Dest:DWORD

invoke lstrlen,Source
dec eax
mov ecx,eax
xor edx,edx
mov edi,Source
mov esi,Dest
.while ecx != -1
   mov al,byte ptr
   mov byte ptr,al
   inc edx
   dec ecx
.endw
mov byte ptr,0
return 0

ReverseStr endp
:):):):):):)
Posted on 2001-03-17 21:55:00 by anon
First thing, try initialozing the value of lo2. It's there to stop the loop, not a good thing to use a random value for. ---------------------- "Iíve figured out an alternative to giving up my beer. Basically, we become a family of travelling acrobats."
Posted on 2001-03-17 21:56:00 by Ernie

RevStr PROC xStr:DWORD
    xor ecx,ecx

    mov eax, xStr
L1: push ecx
    mov cl,
    test ecx,ecx
    jne L1

    mov eax, xStr
L2: pop ecx
    mov , cl
    test ecx,ecx
    jne L2

    ret
RevStr ENDP
I don't like it but it's certainly a solution :P bitRAKE
Posted on 2001-03-17 22:36:00 by bitRAKE
funny whenever i try and invoke either of yours i get an illegal operation.... -brad
Posted on 2001-03-17 23:28:00 by Rage9
Hahaha, I really shouldn't post any code w/o running it :P Forgot to 'inc' the pointer. It just overflows the stack :) This one works:

RevStr PROC xStr:DWORD
    xor eax,eax

    mov ecx, xStr
@@: push eax
    mov al,
    inc ecx
    test eax,eax
    jne @B

    mov ecx, xStr
@@: pop eax
    mov , al
    inc ecx
    test eax,eax
    jne @B

    ret
RevStr ENDP
bitRAKE This message was edited by bitRAKE, on 3/19/2001 12:05:57 AM
Posted on 2001-03-18 00:16:00 by bitRAKE
This is the standard algo in MASM32.LIB for reversing a string, it has been optimised by Alexander Yackubtchik.

; ########################################################################

revstr proc lpszSource:DWORD,lpszDest:DWORD

    push edi

    invoke StrLen,lpszSource

    mov ecx, lpszSource
    lea edx,
    lea ecx,
    mov edi, lpszDest

  @@:
    mov al, 
    dec ecx
    mov , al
    inc edi
    cmp ecx, edx
    jne @B

    mov byte ptr ,0

    pop edi

    ret

revstr endp

; ########################################################################
Regards, hutch@pbq.com.au
Posted on 2001-03-18 01:14:00 by hutch--
Thanx guys, works perfectly! -brad
Posted on 2001-03-18 20:22:00 by Rage9
Without the API call, I think the version I present above is faster and smaller :P
Posted on 2001-03-18 23:04:00 by bitRAKE
Would it not be faster (especially on long strings) to use something like (pseudo code):

invoke strlen source
push eax
and eax 0x3

(Do single byte writes until eax==0)

pop eax
shr eax, 2
(Do DWORD read)
bswap it
write it
I could actually code this but I am lazy :P Anyway The Svin is better at it than me :D Mirno
Posted on 2001-03-19 06:05:00 by Mirno
It would have to be a very long string, as I have the StrLen function integrated into my routine. You have to make up those cycles. A combined DWORD approach is possible I think, but it would be a large routine. bitRAKE This message was edited by bitRAKE, on 3/19/2001 3:10:21 PM
Posted on 2001-03-19 14:04:00 by bitRAKE
to bitRAKE 1. You wrote good proc, it uses classic reversing algo wich was popular in algos used for radix 10 based BIN ASCII conversions to reverse result of divisions by 10 2. Your proc can't be compared to the others posted in this thread. LOOK CLOSELY: - All other procs uses to parameters, yours - one - All other procs put the result in different destination, yours reverse bytes in the same memory range. It changing the string source while others use it as a source to formate another string. 3. Usage: When user wants to reverse the same string, or she wants just formate reversed string from another and doesn't care of saving source untached I would recommend use your algo. Runing simple test we can see that it can be almost twice faster. But in the test we comparing the moon with fried eggs. The procs are different. And I can explain why your proc is faster - it use in second part the same range of memory which is getting into memory cache in the first part of proc. To compare in equal condition we shall change your proc so that in put result in different destination: RevStr PROC SourceStr:DWORD,DestStr:DWORD xor eax,eax mov ecx, SourceStr @@: push eax mov al, inc ecx test eax,eax jne @B mov ecx, DestStr @@: pop eax mov , al inc ecx test eax,eax jne @B ret RevStr ENDP Now if we compare it with revstr from M32LIB your proc will be a little bit slower and almost twice slower than itself working with the same memory as for source and destination. As I said - answer is memory cache usage. Apart from fare testing :) I would include your proc in M32LIB as proc for appropriate cases when user needs to reverse the same string in memory,'cause in this particular case your proc wil be faster. The Svin. ret RevStr ENDP
Posted on 2001-03-20 16:12:00 by The Svin
Svin, I never did like playing fair :) For me there have been rare times when I need the string I was reversing, but I certainly shouldn't ignore the needs of others :) I put mine in a macro that tests if source&dest are the same; then uses the appropriate routine :) Did I mention how small it is and the fact that it compresses well :P Nothing quite like self-similar coding :) You do some fairly awesome coding yourself - want to work with me on some libraries? bitRAKE This message was edited by bitRAKE, on 3/21/2001 7:12:28 AM
Posted on 2001-03-21 05:55:00 by bitRAKE
bitRAKE, Your algo is an interesting idea, there are often instances where modifying the original string is fine if its original form is not needed. About the only problem I can see with it is if you reversed a string that was longer than the amount of stack memory you had available, it would crash but it is rare to reverse a string that long. Nominal stack size in MASM code is 1 meg although you can change it if you require. Standard library stuff must be designed to handle cases of very long strings so a source and destination is necessary but I think your algo is well suited for dedicated applications where the stack limit is never exceeded. Regards, hutch@pbq.com.au
Posted on 2001-03-21 06:33:00 by hutch--
To Hiro: Friend, I tried twice click those code* (I mean in two msgs) and will try again, but it doesn't work in my case! I just got messages that errors ocurred in the script page. To Hutch: Your wish is my command :) Here is another reversing string proc 1. It reverse the same string 2. It doesn't use stack at all 3. It faster than the bitRAKE proc 20-25%. revstr2 proc lpszSource:DWORD invoke StrLen,lpszSource mov ecx, lpszSource lea edx, .while (ecx < edx) dec edx mov al, mov ah, mov ,ah mov ,al inc ecx .endw ret revstr2 endp Please, note: though this revesing algo is twice faster than that presented in revstr, I couldn't use it 'cause revstr supposed to use different range addr as destination. To bitRAKE: Of course, you're wellcome to work with me on some libraries. I'm currently working on alternative proc to FileTimeToSystemTime. As to M32LIB it lacks most useful proc InString case unsencative version. 62 integer conversion routines ect. I have my way to handle it, but haven't found time yet to bring it to M32LIB format. And there is no mathlibrary. The Svin.
Posted on 2001-03-21 09:10:00 by The Svin
What about this for revstr2? (I haven't tested it, and haven't a clue as to how to bench mark it :rolleyes: )

revstr2 proc lpszSource:DWORD

invoke StrLen,lpszSource
.IF eax == 0
  ret

.ELSEIF eax < 4
  mov ecx, lpszSource
  add eax, ecx
  dec eax
  mov dl, 
  mov dh, 
  mov , dh
  mov , dl
  ret

.ELSE
  push esi
  push edi

  mov edi, eax
  mov esi, lpszSource
  add edi, esi
  sub edi, 4

  .REPEAT
    mov eax, 
    mov edx, 
    bswap eax
    bswap edx
    mov , eax
    mov , edx
    add esi, 4
    sub edi, 4
  .UNTIL esi >= edi

  pop edi
  pop esi
  ret

revstr2 endp
Mirno I keep spotting stupid mistakes, I really am a stupid monkey! This message was edited by Mirno, on 3/21/2001 1:17:52 PM And again :( :mad: This message was edited by Mirno, on 3/21/2001 1:19:06 PM And again (again) :mad: This message was edited by Mirno, on 3/22/2001 10:30:03 AM
Posted on 2001-03-21 10:46:00 by Mirno
I really think we should have an Library section on this board where messages of this type could be moved for future reference. I'm not sure what PROCs are needed by MASM, but I'd be glad to help chip away on them - bit by bit you know. I'm working on BB-Tree routines, and related stuff right now for code-completion and high-lighting use in all the IDEs that are being developed for ASM :) bitRAKE
Posted on 2001-03-21 14:00:00 by bitRAKE
I like BitRAKE's suggestion of a seperate area for library development as it is an important area in assembler design. A standard library makes code development a lot easier and a lot faster yet with published source, it is not a straight jacket that restricts improvements or design freedom. I have written what I have had time to write and optimised some of the modules to get their performance up but there is a limit to what any single person can do and the field is truly enormous to cover the range of things that different people write. Alexander's contribution in modules and optimising has made the MASM32 library a lot better and the more that can be developed, the better it will be for most people as no-one can know all of the code designs and type that are required. The idea of a floating point maths library appeals to me. I added a few very simple integer modules using FP instructions in the last service pack to do basic stuff when interacting with API calls where integer resolution is appropriate but having a dedicated FP library in either REAL8 or REAL10 would be very useful to many people. I have another search algo done for binary search which uses the internal algorithm from the InString algo in the library. It is a first character/BYTE search, branch compare, exit on match or continue to end type algorithm. To do case insensitive search with this algo requires case conversion which works OK but there may be a faster way of doing it. Jeremy Collake has written a set of Boyer Moore search algos which benchmark up OK but they were no faster on average than InString but far more complicated. I have this predjudice against the Boyer Moore family of search algorithms and tend to see them as C based antique junk but if someone has a feel for this style of algorithm, it may be a method of doing searches quickly. What I would like to see is programmers from many different backgrounds writing library modules in their own specialisation complete with commented source and reference material. Games, graphics, maths, system etc.... Regards, hutch@pbq.com.au
Posted on 2001-03-21 16:26:00 by hutch--
...but there is a limit to what any single person can do... I'll help if you like, I can't dedicate more than about 4 hours a week, but if you want to give me a specific task, then I'll gladly take it on. And if you need any VAX/VMS assembler writing or PDP-11... oops I'm showing my age... Umbongo
Posted on 2001-03-21 16:36:00 by umbongo
wow this thread really blew up!! Id love to see a library section... -brad
Posted on 2001-03-21 20:26:00 by Rage9