Hey. 
I didn’t break it this time!
Earlier this year, I rambled about Windows XP not-so-good internal text search tool: It’s broken. No matter how you try to find files with specific portions of text, it will not return the right results. No matter if you turn that frigging dog off (‘Assistant, my *ss’), it will not return the files I’m looking for. I know they’re there. I wonder if this is the reason why other companies saw a hole in the market for an invention that was supposed to be there: the Desktop Search Tool! And Microsoft (as you’ve probably found out) has now also launched their own tool, appropriately called ‘Desktop Search’. Why did they break it in XP anyways? Can I sue them now? I mean, I just want to find my files.
Also, while looking around for other tools, I found that most of them were ‘light versions’ (Agent Ransack for example) or bluntly said, overpriced. And while Grep works on Windows (using the GNU tools for Windows), it doesn’t find me files with specific timestamps and creation dates.
Since it was about time to sharpen my algorithm skills, I delved into search routines, studied the Boyer Moore Horspool algorithm and ended up with a quick and dirty search tool. I made a couple of mistakes first. I thought it was smart to use Delphi’s internal objects to load files, but I quickly found out that they’re limited: for example trying to load a 500 MB AVI file (‘Wing Commander’) ended up bombing out on me (the movie was a bomb anyways, but that’s a different story). I decided to change plans radically and chose for the use of Windows memory-mapped files, which meant I had to jump back to Delphi’s Pchars (‘pointer to chars’).
Here’s where the story becomes interesting and where all the logic of Pascal seems to fade away: who decided to have strings start at character 1? (If I remember correctly, the first character in a Pascal string is a pointer to the length of the string). While changing my code to understand pointers and pchars, I ran in an overflow in a while loop, a loop that literally frequently tests if a specific variable has reached until the end of the buffer or (in my case originally) the string. It looks something like this:
while fPos < = textlenght do
begin
The Code....
end;
This works perfect for normal strings: lets say, we have a string with a length of 255 characters. Since our first character starts at 1, telling a loop to continue until we have reached a value smaller or equals works great. Can you tell where the problems start when you work with 0 based arrays and buffers? (hint: 0 + 255 == 254)
Building your own software gives you the right to call it whatever you want to call it: I opted to go for “Fandro” which means something like ‘Vander what?’, the answer some people get when they pronounced their Dutch lastname (also note the appropriate use of Italics). Or maybe just maybe Fandro is a wordplay on the words of a certain Commander in Chief who proclaimed that ‘major combat operations are over’. Except for files then, naturally: Because the irony of everything is that, while you may think you’ve finally got it working again, it ends up broken anyways. Or rather, when you think you have found that darn file, you end up deleting it anyways!
Fandro will be offered as Freeware on xsamplex whenever I think it’s time to throw it out.