filename from path

[zemtex]

you could also scan for the null terminator, which is a safer bet

cld
mov edi, szFileName
xor al, al
mov ecx, MAX_PATH + 1
repne scasb
sub edi, 4
mov al, byte ptr [edi-1]
cmp al, 2Eh
je match
; PERFORM ROBUST CALCULATION FROM THIS POINT IF YOU GET HERE
match:
edi points to file extension



Another example

cld
mov edi, szFileName
xor al, al
mov ecx, MAX_PATH + 1
repne scasb
mov eax, [edi-5]
cmp al, 2Eh
je match
; PERFORM ROBUST CALCULATION FROM THIS POINT IF YOU GET HERE
match:
the 3 h.o bytes of eax now contains the file extension. and if you are looking for an .exe file, you could quickly find out if it is by doing:
cmp eax, 6578652Eh
je foundexefile

[dedndave]

when you scan for the null terminator, you are acquiring the string length
what Hutch is saying is - that may already be done for you if the string came from an API function

of course, if the string is defined in the .DATA section, you can use the SIZEOF operator to get the length

if the user enters a string, however, you will have to get the length
in some cases, the function that returns the string may also return the length
GetWindowText is one example that comes to mind - the length is in EAX
if you use SendMessage to get the string, it may not (depending on the type of control)

[jj2007]

or eax, 20202000h
cmp eax, 6578652Eh
je foundexefile

Just to be on the safe side  :wink

[zemtex]

Yes, I forgot about uppercase and lowercase, but the algorithm is good. I didn't have time to test the code, I wrote that but I edited the post and deleted it again accidentially  :toothy

dave, nobody is arguing whether you are using the api or not, this is just pure algo.  :naughty:
beside, you don't need to extract the file extension from a file dialog, you use filter settings for that. No backscanning, searching or any mumbo jumbo, you simply set the file dialog to accept the specific file types you want.
There are cases when you don't need X, there are cases where you need X. You are arguing that an algorithm is bad because it is partially needed and partially not needed, which is bad logic.

To give a similar example to you: "I don't need to refill my car at the gas station, I already have gasoline on my car"  :toothy

I have made a diagram so that you understand what I am saying:



To take it even further. Here is your line of thinking. "I have solved a problem by using a dead slow function as an excuse to not use a faster one, therefore a different solution is always bad"

What you should have been thinking dave, is "There are two ways of solving a problem, the first solution is just as relevant as the second one, and there are no good reasons to exclude any of them"

....enough logic for now.  :lol

I'm tempted to take it a bit further:

Assumption from your part: "All programmers will put an API function call in front of another call, this is just the way it works. It will happen all the time, in 100% of the cases"

[dedndave]

i was only trying to help

[zemtex]

i was only trying to help

My criticism does not have reverse effect on your help. Perhaps you don't like constructive criticism?  :wink

[dedndave]

you can criticize me all you like - lol

you seem to have missed the point
you are trying to write something that is "fast"
but, you insist on using CLD and REPNZ SCASB
that's not fast

the fact is - the length is often already there for you, as Hutch mentioned
in cases where it isn't - the masm32 StrLen function performs quite well
there may be faster routines, but probably not a lot faster - and this one is already written for you

as for the file dialogs - i was refering to other places where a user might enter a filename, like an edit box or something
i am aware of the file open/save dialogs functionality

quote from Hutch...

Most of you path API functions return the length of the string so you just add it to the start offset to get
the end, then scan backwards to get either the "\", "." or the start of the string if neither are present.

and your reply was...

you could also scan for the null terminator, which is a safer bet

cld
mov edi, szFileName
xor al, al
mov ecx, MAX_PATH + 1
repne scasb

i tried to clarify for you, by trying to examine the cases where the length is provided and those where it is not

it's all good, though
if you don't want help - don't ask for it   ::)

[zemtex]

you can criticize me all you like - lol

That was not a given, as I deduced  :lol

you seem to have missed the point
you are trying to write something that is "fast"
but, you insist on using CLD and REPNZ SCASB
that's not fast

I  have several implications here.

1: Instead of saying "is not fast", why do you not do as you always do, present an improvement like you always do, there are no reasons to step aside from that practice and sort to negativity.
2: working with strings, string instructions are almost always faster.
3: I used the term "faster one", which means relatively to the chunk you proposed to me (1 api + an extra algo of your own) You are making up thoughts of your own here.
4: "that's not fast" is another example of bad logic. "not fast" is a relative term.
5: I am not  "trying to write something", I have already written it, without testing it i might add. And I never needed the function, it was just for fun.
6: I have not missed the point, I have given you very accurate (with pictures) that your logic is bad.
7: About "You can criticize me all you like", the question is if I could have done that without telling you first. I leave that question to stay unanswered :)

the fact is - the length is often already there for you, as Hutch mentioned

Nobody is arguing about the length, the length is just a bieffect in my algorithm, and in your case it is a tool achieved by a slower algorithm.

in cases where it isn't - the masm32 StrLen function performs quite well

The StrLen function has got nothing to do with what we are talking about. What you are saying here is that "There are more green apples in africa, even though you have an apple tree in your own garden"

there may be faster routines, but probably not a lot faster - and this one is already written for you

When did this become a discussion of which is the fastest routine in existence?  :P You have missed the point yourself.

as for the file dialogs - i was refering to other places where a user might enter a filename, like an edit box or something
i am aware of the file open/save dialogs functionality

I do not care about your private popup where people have to type manually, in windows the default behavior is to use a file dialog. The second thing I want to say about this is that even though you propose examples of where it does not work, is not an argument for situations where it does work and where it is helpful. And it is definitely not an argument against the algorithm itself.

quote from Hutch...

Most of you path API functions return the length of the string so you just add it to the start offset to get
the end, then scan backwards to get either the "\", "." or the start of the string if neither are present.

hutch is a wise man.

and your reply was...

you could also scan for the null terminator, which is a safer bet
It was not a reply to hutch, it was yet another example and I am well aware of the length being returned by api functions that is why I didn't comment it, it is a normal way of doing things in windows.

it's all good, though
if you don't want help - don't ask for it   ::)

I want help, but the length returned by API functions is not exactly what I was looking for, I would say you have a tremendous grasp of the obvious.

[dedndave]

knock yourself out, buddy

you want me to draw you a picture, with circles and arrows ?

[dedndave]

[zemtex]

  :U

You might want to practice

[dedndave]

if extracting a few characters from a string is too difficult for you,
then i suggest that maybe assembly language isn't for you....

http://www.vbforums.com/

[zemtex]

if extracting a few characters from a string is too difficult for you,
then i suggest that maybe assembly language isn't for you....

http://www.vbforums.com/

I am going to take this step by step, I realize what your lack is, read very carefully.

1: In my first post I ask for a function in the masm32 library so that I don't have to write it myself.
2: In a later reply of mine, I explicitly write that I have written this kind of function many times before.
3: I have already laid out an example how this can be done.

The problem here is that you are not thinking rationally, you are judging by emotions. Your emotions are stirred up, and these emotions are making you think the problem is real, there are no problems around this functionality that I have described, I have even written an algorithm for it in an earlier post.

You are not thinking clearly.

[jj2007]

Wow, this looks like fun :U
My bottle of red wine is already half empty, time to join the club with a modest contribution:

Code Select Expand

include \masm32\include\masm32rt.inc
.code
ThePath db "C:\Masm32\Stupid folder\Stupid sub folder\this is the file.exe", 0
start: mov edi, offset ThePath
xFile: or ecx, -1
xor eax, eax
repne scasb
not ecx
add eax, 92+0 ; put 92+1 to simulate the "nnt found" case
std
repne scasb
cld
jecxz NotFound
add edi, 2
NotFound:
.if ecx
print "We found it: ["
.else
print "No luck: ["
.endif
print edi, "] in just "
mov eax, NotFound
sub eax, xFile
inkey str$(eax), " bytes"
exit
end start

Any volunteers for pushing it below 21 bytes? Speed is an issue, of course: On my trusty Celeron, parsing the path above takes a whopping 0.27 microseconds. If you have a Million paths to parse, that makes it 0.27 seconds ::)

[qWord]

ABI-friendly, 18 Bytes, no sting instructions:

Code Select Expand

mov edx,offset ThePath
xor ecx,ecx
@@: movzx eax,CHAR ptr [edx]
test eax,eax
jz @F
xor eax,'\'
cmovz ecx,edx
inc edx
jmp @B
@@:
.if ecx
lea ecx,[ecx+1]
print ecx,13,10
.else
print "damm",13,10
.endif
Prost  :bg