LookingFor: A Masm64 tool to find strings in files.

[HSE]

Hi all!!

This is a little tool with JJSearch tool general concept (also known as FindOnDisk), wich is a very useful tool with some limitations. I made the new tool following Hutch's style and can be integrated in Masm64 SDK if tests are successful.

In this case, tool is limited to ANSI strings, and will fail with very long name files or non latin characters in directory names. I have one of each in the programming disk, then I erased that little noise 

The file system exploration is a classical example from Masm32 SDK, obviously translated to 64 bits.

Boyer-Moore implementations are from Mineiro's code. A little modification was critical, because that implementation crash when file size is an exact multiple of page size (like probably happen in many others tools that fail in my disk).

Critics and suggestions are welcome 

Regards, HSE.

[HSE]

Added update of targets list modifications between application instances running simultaneously.

Updated files in first post.

[jj2007]

Wickedly crafted

[Biterider]

Hi HSE
Cool application. Tested the binary here without any problems. 

Biterider

[greenozon]

Very interesting tool, thanks for your efforts HSE!
some feedback:

1) help button wanted to find .pdf file, is it available?
---------------------------
LookingFor:
---------------------------
Could not open LookingFor.pdf
---------------------------
OK 
---------------------------

2) I'd add some "Stop" button in case the end-user set some wide mask eg: "c:\"
the only way is to kill app then...

3) I tried to search some sample patterns (two) and after some time the app crashed
I've got crash dump in case of interest

https://prnt.sc/BFCNqFg2J3Tt    (Picture from VS opening crash dump)

[HSE]

Hi greenozon!

1) help button wanted to find .pdf file, is it available?

Yes, in .zip with binary. In .zip with source there is a .tex file to build .pdf.

the only way is to kill app then...

Yes, that is the way 

3) I tried to search some sample patterns (two) and after some time the app crashed
I've got crash dump in case of interest

That is szappend function in m64lib. The most probable thing is that your disk have a long path, or an  Unicode name in a file or directory. Building in console subsystem and TRACKING_CRASH equ 1, will show files correctly accesed, then the problem is close to last one.

In C:\ is most probable to have long paths or unicode names. I can search 260 Gb in D:\ after remove one of each, but to search in C:\ need to be more specific.

Anyway, if you write unicode files everywhere, a so simple ASCII search will not work for you.

Thanks very much, HSE

[HSE]

Thanks JJ and Biterider 

[greenozon]

You are right,
I was scanning C:\tmp that has the hell amount of trash :)
and yeah - it has weird dir names even including emojis!

do you support that zoo?

[HSE]

do you support that zoo?

It's mostly a tool to assist programming. And the targets are very simple ASCII files.

Because I don't even have tabs in most files, I forgot that 

Updated in first post.

[NoCforMe]

Very interesting tool, thanks for your efforts HSE!
some feedback:

2) I'd add some "Stop" button in case the end-user set some wide mask eg: "c:\"
the only way is to kill app then...

I second that emotion.

My own file-finder app runs the disk-scanning code in a separate thread with a "Cancel" button visible to stop things if they run too long. Very easy to implement.

[HSE]

emotion.

¿? 

  A better solution. Updated in first post.

Thanks, HSE.

[greenozon]

Tried the fresh bits from 1st post
sometimes app exists (crashes? but no core dump) in case you press "Find" but not set base directory
https://prnt.sc/AS-Y42QDxHSb
Also if base dir is empty the "Cancel" button continues to be visible instead of "Find" as no operation was started...

[HSE]

Hi greenozon!

sometimes app exists (crashes? but no core dump) in case you press "Find" but not set base directory
https://prnt.sc/AS-Y42QDxHSb

That it's weird. A message box open when no valid path (at least "\") or no validad file name (at least "*") is provided.

But I have to see because "\*" have to fail, but that work if first run "\*.*". Something remain in some buffer. Perhaps I will take some time and try to improve all path thing. 

Also if base dir is empty the "Cancel" button continues to be visible instead of "Find" as no operation was started...

Corrected 

Thanks, HSE.

[greenozon]

Nice, nice! great progress

but still hitting crash dumps sometimes, eg:

https://prnt.sc/Rl0sPvzGc7HS

[HSE]

Hi greenozon!

but still hitting crash dumps sometimes, eg:

  Apparently that is an ASCII MessageBox with a Unicode string. A little more elaborated error processing is not working yet.

Updated in first post.

Thanks, HSE