Works also with m.a.n.y d.o.t f.i.l.e.s ;)



invoke lstrlen, addr szPath
mov ecx, szPath
add ecx, eax
@@:
dec ecx
cmp byte ptr [ecx], "."
jne @B
mov byte ptr [ecx], 0
@@:
dec ecx
cmp byte ptr [ecx], "\"
jne @B
inc ecx

; invoke MessageBox, 0, ecx, ecx, 0, 0
Posted on 2001-12-30 21:23:59 by bazik
you might want to load string offset into another register, and do
(eg) , and in check if ecx becomes zero... not all files have
extension, not all files have path....
Posted on 2001-12-30 22:16:12 by f0dder
Slow code...
Posted on 2001-12-31 00:07:36 by buliaNaza
i dont realy understand the code

what does it do ? for example you have a string
c:\windows\system32\cmd.exe

what will you get from this just the "cmd"?
but what if the file is "c:\windows\a"
like f0dder said your algo doesnt check if the string is over
moreover if you have a string like my example the first loop will continue and continue and youw will skip on the '\' (hope you understood what i tring to say here)



bye
eko

p.s you dont need to check the last and the first bytes for '.'
Posted on 2001-12-31 04:35:13 by eko

what does it do ? for example you have a string
c:\windows\system32\cmd.exe

what will you get from this just the "cmd"?


Yes :)
I wrote it for my Media Player... if you open an mp3 file, it will read out the ID3 tag and adds "Artist - Title" to the listbox. If you open an wav, wma, mpeg, avi, mpg etc. it will show the filename without extension and path.
example:


F:\DivX\Tomb Raider.avi

becomes


Tomb Raider


In the case, I use this code, the files ALWAYS have a extension, and because I get the names from a GetOpenFileName box, they always have a path, too.

Originally posted by buliaNaza
Slow code...


Hehe, I waited for such a reply ;)
It's fast enough for me, but it would be great, if you could post a optimized version. But if you do so, please comment it well, so I can learn from it :) Thanx in advance!

bAZiK
Posted on 2001-12-31 07:28:29 by bazik
How often is the filename splitting routine called? Would you really
need to optimize it? Focus your attention on the 10% that runs 90%
of the time instead of wasting your energy on this...
Posted on 2002-01-01 10:25:05 by f0dder

How often is the filename splitting routine called? Would you really
need to optimize it?


I don't need to optimize it. It's called for every file, wich is added to the listbox... and it's fast enough for my needs.
But some guys in this forum think, they must optimize every thing....
:tongue:
Posted on 2002-01-01 10:42:29 by bazik
Here is my version. It works well too :grin:.


#include "shlwapi.h"

TCHAR lpszPath[] = TEXT("c:\\path\\file.ext");
LPTSTR lpszFileName;

PathRemoveExtension((LPCTSTR)lpszPath);
lpszFileName = PathFindFileName((LPCTSTR)lpszPath);
Posted on 2002-01-01 11:04:44 by LuHa
WOW, only 2 lines of code, and NO loop :grin: :grin: :grin:
Posted on 2002-01-01 11:24:17 by bazik
luha version : only two line maybe shorter but no one say FASTER . those api can be even slower and be sure they have loop inside them
Posted on 2002-01-01 15:25:54 by eko

luha version : only two line maybe shorter but no one say FASTER . those api can be even slower and be sure they have loop inside them


I know :) just kidding =)
Posted on 2002-01-01 16:57:32 by bazik
So what if they're a bit slower... filename processing is not exactly
what will be run 90% of the time... unless you have some *very*
specific needs ;). And if speed isn't critical, why not go for smaller size...?
Posted on 2002-01-01 17:47:16 by f0dder
f0dder
:
smaller code. . not much
still you have push call push call again and mov .
am.... yeah it still smaller so i guess you are right :rolleyes: .


bye

eko
Posted on 2002-01-02 07:35:31 by eko

f0dder
:
smaller code. . not much
still you have push call push call again and mov .
am.... yeah it still smaller so i guess you are right :rolleyes: .


bye

eko


He is wrong.
Posted on 2002-01-03 02:44:59 by The Svin
and programs using the functions from shlwapi need a dll (shlwapi.dll) that comes with IE 4.0 and higher...
shlwapi has lots of useful string manipulation functions though.

I would also be glad to view optimizations to BaZiK's version...
Posted on 2002-01-03 10:08:05 by JCP
It was not my intention to start such a discussion when I posted my reply, I was only joking. I'm not a fan of blind optimization (I don't even use asm, I don't need it for my little apps and I don't know it :rolleyes: ). I think bAZiK's solution is better if you plan to run your app on win95+, but if your app already need win98+ (shlwapi.dll comes with the OS), well, just use two api calls and be happy, don't warry if it will add an overhead of 20ms (of course if you have a file list of 100000 entries to parse, bless bAZiK and reuse his code :grin: )
Posted on 2002-01-03 12:22:37 by LuHa
Yes LuHa, i did understand it was a joke but it can start a discussion too... ;)
In my opinion it is important to enumerate all possible ways to do something and to discuss about their advantages and inconvenients...

shlwapi is a very useful dll indeed but personaly, i try to write assembly or C equivalents to its functions when I have to use it because of this runtime dependency.

Kind regards,
Posted on 2002-01-04 07:42:50 by JCP
		mov eax,offset szPath

@@: cmp byte ptr [eax],"\"
je @_s
cmp byte ptr [eax],"."
je @_p
cmp byte ptr [eax],0
je @_z
inc eax
jmp @B
ALIGN
@_s: mov edx,eax
inc eax
jmp @B
ALIGN
@_p: mov ecx,eax
inc eax
jmp @B
ALIGN
; you could do error checking here...
@_z: mov [edx],0
mov [ecx],0
inc edx
; EDX is string start...
This is slower, maybe?
Posted on 2002-01-04 22:12:21 by bitRAKE
Thanks bitRAKE for replay...
I have similar idea but now I'm a little bit busy to finish....


; eax->lpString ; must be ALIGNED
;.....................................................................;
mov esi, eax ;save lpString in esi
xor edi, edi ;
Search_1: ; look for "\"
mov ecx, [eax] ; ecx=4 bytes
add eax, 4 ; ready to get next four bytes
mov edx, ecx ; save 4 bytes in edx
sub ecx, 4D4D4D4Dh ; 4Dh=4Ch+1h ->4Ch="\" ;v sub from each byte in ebp
and ecx, 80808080h ; look for "\"-> test sign
jnz Search_14 ; if not loop again
mov ecx, edx ; save 4 bytes in edx
sub edx, 2F2F2F2Fh ; 2Fh=2Eh+1h ->2Eh="." ;v sub from each byte in ebp
and edx, 80808080h ; look for "."-> test sign
jnz Search_15 ; if not loop again
mov edx, ecx ; save 4 bytes in edx
sub ecx, 1010101h ; 01h=0+1 ->0 ;v sub from each byte in ecx
and ecx, 80808080h ; look for 0-> test sign
jz Search_1 ; if not loop again
test edi, edi ; if edi=0 no "."
jz S_Ret ;
mov dword ptr [edi], 0 ; edi-> lp of last "."
S_Ret: ;
mov eax, esi ; eax->return address of file name
ret ; exit

Search_14:

....
....

jmp Search_1
Search_15:
....
....
jmp Search_1
Posted on 2002-01-05 01:14:32 by buliaNaza
buliaNaza, I was hoping you'd reply as well. ;)

Similarly, I don't have the time to finish this right now. ;)
	mm_5C dq 5C5C5C5C5C5C5C5Ch ; lots of "\"

mm_2E dq 2E2E2E2E2E2E2E2Eh ; lots of "."

ReturnFileName:
mov ebx,[esp+4]
mov esi,ebx ; there is atleast one "\" so first byte is not
mov edi,ebx ; important - possible zero it later
movq mm7,mm_5C
movq mm6,mm_2E
pxor mm5,mm5
MAIN: movq mm0,[ebx]
movq mm2,mm0
movq mm4,mm0
pcmpeqb mm0,mm7 ; "\"
pcmpeqb mm2,mm6 ; "."
pcmpeqb mm4,mm5 ;null char
; Word FFFF = FF byte = 11 111111
; Word FF00 = 80 byte = 10 000000
; Word 00FF = 7F byte = 01 111111
; Word 0000 = 00 byte = 00 000000
packsswb mm0, mm0
packsswb mm2, mm2
packsswb mm4, mm4
movd eax, mm0
movd edx, mm2
movd ecx, mm4
add ebx,8
test eax, eax
jne _5C
_2E_: test edx, edx
jne _2E
_00_: test ecx, ecx
je MAIN
_00: mov byte ptr [edi],0 ; additional error checking here?
lea eax,[esi+1]
ret
_5C: bsf eax,eax
shr eax,2
lea esi,[ebx+eax-8]
jmp _2E_
_2E: bsf edx,edx
shr edx,2
lea edi,[ebx+edx-8]
jmp _00_
There are plenty of MMX registers to double over the algorithm to process 32 bytes each loop and keep the constants in registers. This algo could be adapted easily to unicode and allows the full range of the bytes. It might actually be worth it to code and algo like this to proccess URLs?

Edit: Okay, the above appears to be a working version?
It is not. :tongue:
Posted on 2002-01-05 02:07:54 by bitRAKE