Building WinFindr, the best Windows search tool

WinFindr – Or how I realized Windows Search is so bad, I had to build a better Windows search tool

Wise men don’t need advice and the fools won’t take it. I think someone a lot smarter than me once said something along those lines. Obviously, I’m not a wise man.

I’m a simple engineer and when I see something that isn’t working properly, I just can’t let it go. I can end up working for weeks or months on something, just because I think it is not good enough and I need it to be better.

I once heard a grim joke about the French revolution. They supposedly had a rule that if the guillotine’s blade failed to move, you got to walk away free, because it was clearly not your time yet. One day the guillotine had already failed with three people in a row, and then the fourth man was about to step into it. He looked around the menacing contraption for a while, figuring out how it worked, then he smiled and exclaimed, “I’m an engineer, I know how to fix it!”

Yeah, that’s basically me.

As a programmer, I often get the nagging feeling that I have this file saved somewhere in my work computer, but I cannot recall where it is.

I have, of course, tried Windows Search as the first attempt before resorting to popular data searching apps like Everything and RegEdit. However, they still didn’t quite solve my problem. Let me explain.

The problem with Windows Search

Naturally, the first instinct is to use Windows Search. I mean, it’s right there. Right there on the taskbar, like it’s teasing you: “Go ahead. Search something with me! I dare you!”

And as basically everyone knows, you are more likely to read the correct time from a broken clock than find something you were actually looking for with Windows Search.

When I type in “Invoice PDF” I actually mean that invoice_september_12_23.pdf file that is literally right there on my desktop, not some Bing search results about where to get the best “PDF Invoice Templates”.

The problem with Everything

Later, I downloaded and installed a wonderful app called Everything by Voidtools.

It’s one of those simple and straightforward Windows apps that just do what they are supposed to do and they do that very well.

I have been using Everything for years now. And I think it’s great!

Unfortunately, there are some things that I don’t like about it.

The main problem for me is that Everything only works with files and folders. Sometimes I also want to search for registry data, and the Search feature in the Windows Registry Editor (RegEdit) is very limited and Everything cannot search for registry data at all.

Another thing is that the current official version of Everything (version doesn’t support dark mode. Which is kind of sad. It’s 2023 and literally everything should support dark mode user interface already. If you are a fellow software developer reading this and if whatever you are building doesn’t support dark mode, please consider taking the time to gently slap your face.

Yes, I know there is a version 1.5 Alpha of Everything that supports dark mode. It has been in development since March of 2021. I’m not holding my breath waiting for it to be officially released, and I would prefer not to run Alpha stage software on my work computer.

The problem with other popular Windows search apps

So, I did some research to find out what apps are available for Windows just to search for data.

The most popular ones seem to be:

  • Agent Ransack
  • Everything
  • Listary
  • Locate32
  • RegScanner
  • Registry Finder
  • UltraSearch

Sadly, none of them really do what I wanted: I wanted to search for files, folders or registry data, all at the same time, using many search terms at the same time.

This became especially clear when I was working on Uninstalr, what I think is the best Windows app uninstaller.

During its development, I wanted to write down a list of search terms and see every file, folder, registry key and registry entry that matched any of the terms.

For example, I could write the names of apps as search terms, see what files and registry data they had created, then I could uninstall the apps and run the search again to see how much of their data was left behind.

None of the common Windows data searching tools were able to do that.

About ease of use

While Everything is very good in finding just the file system data (files and folders), I have often found it to be rather difficult to use. Perhaps difficult is a wrong word. Obscure or awkward might be a bit better.

Let me explain.

For example, I wanted to look for all the files and folders a bunch of apps had created. So I read the fine documentation of Everything, and I found out, to be able to look for data with many search terms in a way any file is listed as a match if it matches any of the given search term, you can just write the search terms separated by the | character.

So, I typed in: Winamp | Winzip | Winrar and so on. And it worked just fine. Great!

But then I did the unthinkable, and wrote: Winamp | Winzip | Winrar | Visual Studio.

Naturally, it would display all search results that contained any of those search terms?

Nope. It produces an empty results list.

Surely there is some kind of indication in the user interface that what I did was wrong? Nope. All you get is a blank results screen.

I assumed it was a bug and moved on.

I later found out that you must put any search terms with space characters inside quotation marks in Everything. So Winamp | Winzip | Winrar | Visual Studio does not work, and not only does it not work, it doesn’t show any kind of error message either. Just a blank screen. Instead, you are supposed to type Winamp | Winzip | Winrar | “Visual Studio” and then it will work.

As an engineer, I kind of understand the logic behind this. But then again, I just think it could be a bit easier to use.

This is the kind of thing I mean. Everything is great. But it can be a bit obscure at times.

Of course, it’s my fault. It’s my fault for not reading the documentation well enough.

On a non related note, the documentation of Everything is around 50 000 words. The FAQ alone is about 2000 words.

So yes, mea culpa, mea culpa, mea maxima culpa. I didn’t read the whole documentation just to find some files.

How I ended up developing a new Windows search tool

It was around this time when the idea started to slowly enter my overworked and tired brain: I needed a tool that could search data in Windows. It should be able to find both file system data and also search the Windows registry. And it should be easy to use.

Of course, anyone who starts to build software wants to make it easy to use, so in that sense having a design goal of ease of use seems a bit superfluous.

When I’m thinking about ease of use, I’m mostly thinking about how intuitive a user interface is to use.

Imagine you give an app to someone who has never seen that before and you tell them to perform a task, such as “Find all PDF files from your computer which are smaller than 100 MB and include the word ‘invoice’ inside the contents of the files.”

The faster they can do it, the more intuitive a user interface is to use.

That is how I ended with the idea that I should develop WinFindr.

The challenges in making a better Windows search tool

Before too long into the development, I dived deep into the rabbit hole of obscure search algorithms and how to open and parse Microsoft Doc or PDF files.

That’s another thing.

When I think about a search app that can also search for document files based on their content, what I’m thinking as an engineer is text files. Files that are just text, encoded in some way such as in Unicode or ANSI if you are a brute, but essentially files that are just text. Such as those .txt files you might remember. Or if you are a programmer, files such as .php, .js or .c are essentially text files.

Finding text files based on their content is trivial: Just open up and read each file, scan whether they include the user’s search terms and that’s it. Not very quick, but very easy.

But if you are going to tell anyone that your software can search for files based on their content, they are probably not going to think of text files like these. They will probably think files like Microsoft Word files, or if they are people of culture, OpenOffice Odt files. Or those damned PDF files.

These kinds of document files seem to be just text files to the user, because the user can just double click them open, and they just contain text.

But the way how Microsoft Word or OpenOffice Writer files actually work is much, much more complicated. That’s because they can include images, tables, different font settings and so on.

This is how an actual text file looks like:

Screenshot of a txt file

Behind on the screenshot is my text editor, Notepad++ and in the foreground, a hex editor which basically means an app that can open any kind of file and display its raw content.

As you can see, a .txt file is very simple: all it contains is the text you have typed.

Therefore, it’s trivially easy to write an app that simply opens such a file and searches for any terms within its content.

But let’s see how a Microsoft Word document looks like:

Screenshot of a Docx file

What you see as the user in Microsoft Word’s user interface is the exact same text, but if we look at what the document.docx file actually contains, it’s entirely different.

Here is how OpenOffice Writer’s ODT document format looks like:

Screenshot of an ODT file

And here is how a PDF file with the exact same text content looks like:

Screenshot of a PDF file

As you can see, trying to open document files such as Microsoft Word, OpenOffice Writer or PDF files to search for content inside them isn’t all that easy.

But I didn’t start to do this because it was easy. I started to do this because I thought it was easy.

I was wrong, and after a long time in trying to understand how these different file formats worked, I got it working.

I’m sure there are versions of these file formats that don’t work right now, but I can improve on this in the future.

The support for PDF files is especially difficult, because there are so many different types of PDF files. The WinFindr 1.3’s PDF content searching supports only a text-only type of PDF files. Not PDF files which contain the data in bitmap format. As to why, please refer back to the point where I say I’m a simple engineer.

In any case, this is how it looks like:

WinFindr, a Window search tool supports searching PDF files

After adding support for document files, I was thinking what else I should do. Because if it’s worth doing, it’s worth overdoing.

So, I also added support for Zip and Rar archive files. This means that the new WinFindr version 1.3 can find files inside Zip and Rar files as well.

WinFindr, a Window search tool supports searching inside ZIP and RAR archives

And here is how the results look like:

WinFindr search results

End note

In hindsight, what I developed is nothing like Windows Search and it’s also very different compared to Voidtools Everything.

But I think what I have built is something that has real use cases and value. I have found myself using WinFindr more and more every day.

I hope you will like it too! Please give it a try:

NOTE: WinFindr version 1.3 is a public preview version, released to collect feedback from users. Especially the new search inside files features are currently experimental and not yet fully functional.