Tech stack

KillerFind is a native Windows app. There is no Electron, no browser engine, no runtime to install, and no background service. Everything below ships inside a single .exe that runs on its own:

Install & data

KillerFind is a single .exe. Put it anywhere and run it as is, or use the built-in installer, which copies the app into your user folder, adds a Start Menu shortcut, and registers a normal Windows uninstall entry just for your account. It needs no admin rights, no .NET runtime, and nothing else installed.

Your settings, such as the last folder you searched and your theme choice, are kept in the registry under your own account rather than in a file next to the .exe, so the program stays a clean single file you can move around. When you run it from outside its installed location, a PORTABLE badge appears so you know which copy you are using.

The search pipeline

A search is one continuous pass over a folder tree. You give KillerFind a starting folder and one or more search terms, then it walks every file underneath and tests each one against your terms as it goes. There is no separate indexing step and nothing is stored between runs, so the first search on a folder is just as fast as the tenth.

Each term is either a name term, matched against the filename, or a text term, matched against the contents of the file. You can mix as many of each as you like in a single pass, and optional include and exclude filters narrow which files are looked at in the first place. A piped tab - search within results - runs this same pass over a snapshot of another tab's result list instead of walking a folder.

Matching files

Every file that clears the filters is tested against each of your terms. The two kinds of term work differently.

Name terms: wildcards

A name term is a wildcard pattern tested against the filename. An asterisk stands for any run of characters and a question mark stands for a single character, the same shorthand Windows itself uses. The pattern is turned into an anchored regular expression once, so *.log matches any name ending in ".log" and report_?.txt matches "report_1.txt" but not "report_final.txt".

Text terms: reading inside files

A text term looks for a run of characters inside the file. Before reading, KillerFind checks the first few kilobytes for a null byte, which almost never appears in text but is common in programs, images, and archives. If it finds one, the file is treated as binary and skipped, so a content search does not waste time scanning a photo or an .exe.

Files that pass that check are read one line at a time through a buffered reader that also honors a byte-order mark if the file has one. The whole file is never loaded into memory at once, so a multi-gigabyte log is no heavier to search than a small note. Each line that contains the term is recorded with its line number and its text, trimmed of surrounding whitespace - up to the first 100 matched lines per file, so one pathological file cannot flood the results.

Filters & multiple terms

Include and exclude filters decide which files are looked at before any term is tested. Both take a list of patterns separated by semicolons, trimmed of spaces. Alongside them, filter rows narrow the pass by extension, date modified, or file size; a file must clear every active filter before any term is tested.

• Include patterns are wildcards tested against the filename. When any include is set, a file has to match at least one of them to be searched at all, so *.txt;*.log limits the pass to text and log files.
• Exclude patterns work two ways at once. A pattern that matches a folder name anywhere in the path, such as bin, obj, or node_modules, drops everything under that folder. The same pattern is also tested as a wildcard against the filename, so *.min.js skips minified files wherever they sit.

Every term you add runs in the same single pass over the tree, so searching for three names and two phrases costs one walk of the folder, not five. Each term keeps its own running match count, shown as a small badge next to it, so you can see at a glance which patterns are hitting and which are not.

Streaming, memory, and cancellation

The reason KillerFind can start on a huge folder like your whole user profile without a long wait is that it never builds a list of the tree up front. The walk yields one file at a time and the search reacts to each file as it arrives, so work begins on the first file instead of after the last. Folders it is not allowed to read are quietly stepped over rather than stopping the search.

The search itself runs on background workers, one per CPU core, which keeps the window responsive and lets a long search be canceled the moment you ask. Results are collected and handed to the UI in batches on a fixed timer, about once every 150 milliseconds, along with the running file count and the file currently being read. That single, gentle pace is what stops a fast search from flooding the interface with thousands of tiny updates.

Memory stays flat because nothing large is ever held at once. Files are read through fixed 64 KB buffers, content is streamed line by line, and only the lines that actually matched are kept. A search across hundreds of thousands of files uses about the same memory as a search across a handful.

Export

Any result set can be written to a self-contained HTML report: the matched files, the matched lines with their line numbers, and the search that produced them. The report is a single file that opens in any browser with no dependencies, which makes it easy to attach to a ticket or keep as a record of what was found and where. A CSV export sits alongside it for spreadsheets.

Themes & languages

KillerFind ships with six themes (Dark, Light, Black, Blood, Greed, and Cyanotic), each with its own set of accent colors, all switchable live from the toolbar. The interface is localized in eight languages: English, Spanish, German, French, Turkish, Chinese in both Traditional and Simplified, and Bengali. Every visible string is resolved through a resource lookup, so switching language reflows the whole window with no restart.

Glossary

Plain-language definitions of the terms used on this page, in alphabetical order.