Tech stack

Requires .NET Framework 4.8 (x64). The app's other dependencies are packaged in one executable.

Install & data

Run the .exe from anywhere and a PORTABLE badge appears in the title bar. Click it to install: for just your account, which needs no admin rights, or for every user on the PC, which asks for permission once and puts KillerShell in Program Files with a Start Menu and Add/Remove Programs entry for everybody. Installing for all users removes an existing per-user copy, so there is only ever one install and one uninstall entry, and your theme, accent, language and tabs are kept. Settings live in the registry under your own account rather than beside the .exe, so the program stays a single file you can move around. Requires .NET Framework 4.8 (x64). The app's other dependencies are packaged in one executable.

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.

Installing also registers KillerShell with Windows. The install folder goes on PATH, yours or the machine's for an all-users install; its text types appear under Open with and Default apps; folders and drives get an Open in KillerShell row; and the terminal class described under The terminal is registered. A portable copy registers nothing with Windows until you ask it to.

Opening folders in KillerShell

A double-click on a folder or drive runs the default verb of Directory\shell or Drive\shell, which Windows checks before the Folder class that This PC, the Recycle Bin and Control Panel share. Open folders in KillerShell, in the About card, sets both defaults under HKCU\Software\Classes to KillerShell's own Open in KillerShell verb. A program that asks Windows to open a folder asks for the open verb instead, so the setting writes an open verb under both keys as well. A program that runs explorer.exe itself still gets Explorer. Each folder opens in a window of its own, through --new-window.

Only an installed copy can turn it on, and only for your own account. What it replaces is set aside first: the previous defaults as FolderOpenerPrevious under HKCU\Software\KillerShell, and another program's open verb, whole, under HKCU\Software\KillerShell\FolderOpenerPreviousOpen. Unticking it, Remove registration on the File associations card, and uninstalling all put them back wherever the value is still KillerShell's. An all-users uninstall does this for every user on the PC. A signed-in user's hives are already under HKEY_USERS; a signed-out user's NTUSER.DAT and UsrClass.dat are loaded there only for as long as the work takes, using the backup and restore privileges that administrators and SYSTEM hold, then unloaded.

What is kept where

Preferences are values under HKCU\Software\KillerShell. They include WindowBounds, the size and place of the last window closed, where every new window opens, and PerformanceLayout, the arrangement of the Performance cards. Start with Windows adds a KillerShell value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run that starts it minimized. Working files live in %LOCALAPPDATA%\KillerShell: the prompt scripts, the unpacked KillerPivot and KillerScripts modules, per-window terminal state, service-actions.log for service actions that failed, and crash.log, which records unexpected exits. handoff.log is written there only while the HandoffLog value is 1. KillerShell never sends any of these files anywhere.

Uninstalling

Uninstall removes the program folder, the shortcuts, the PATH entry, the Start with Windows value, the file associations and the terminal class, and puts back the default terminal and folder opener that KillerShell replaced. A per-user uninstall also deletes HKCU\Software\KillerShell. An all-users uninstall deletes HKLM\Software\KillerShell and leaves each user's preferences; other accounts that used KillerShell as their default terminal get Windows' own console window again. %LOCALAPPDATA%\KillerShell is left in place.

The search pipeline

A search walks the folder tree and tests files as they arrive. No index is built or retained between searches. Timing can vary with the files, storage and operating-system cache.

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 matches any run of characters and a question mark matches one character. The pattern is prepared once and matched directly without regular expressions, so *.log matches names ending in ".log" and report_?.txt matches "report_1.txt" but not "report_final.txt".

Text terms: reading inside files

Before matching content, KillerShell detects the text encoding and decodes a bounded probe. A null character in the decoded text marks the file as binary, so UTF-16 and UTF-32 text are not rejected just because their raw bytes contain zeros.

Files are decoded with byte-order-mark detection and Unicode-aware text handling. Content is streamed through bounded buffers without loading the whole file at once. Up to 100 matching-line previews per file are retained; long previews are bounded, and incomplete reads are reported.

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 KillerShell 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.

Search runs on two to sixteen background workers, selected from the CPU count. Results reach the UI in batches about every 150 milliseconds. Cancellation is checked while walking folders, matching patterns and reading content.

File contents are streamed through bounded buffers, and matching-line previews are capped. Result rows remain in memory, so memory use grows with the number of results; it is not constant for every search.

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. A Storage Analyzer scan exports the same way: a single HTML file carrying the current filters, an SVG treemap, ranked folder and file tables, and a file-type color legend.

File operations

Copy and move run on a background worker with a progress card showing the current file and a real byte count, so a large copy never freezes the window. A name collision at the destination stops the worker and asks, showing both files' size and date, with Replace, Skip or Keep both and a "do the same for the rest" checkbox. The worker genuinely waits on that answer rather than copying ahead of it, so nothing is overwritten while the question is still on screen.

A move within one volume is performed as a rename, which is a directory-entry change rather than a data copy, so it is instant whatever the size. Across volumes it copies first and deletes the source only once the copy has landed. Sending to the Recycle Bin is the one operation that goes through the Windows shell, because there is no other way in, and that is also what puts it on Explorer's undo stack, so Ctrl+Z in Explorer brings the files back.

Drops onto a browsed folder follow Explorer's modifier rules exactly: Shift moves, Ctrl copies, and neither means move within a drive and copy across drives. Files already sitting in the target folder are ignored rather than raising a collision with themselves, and a folder cannot be dropped into its own child.

Bookmarks are the exception: a drop onto one always moves, across drives too, because you drop something on a saved place to put it there. A drop onto the Recycle Bin bookmark recycles the files the way Delete does, and holding Shift deletes them permanently, as Shift+Delete does.

Archives

No new dependencies

A .zip, .tar, .tar.gz, .tgz or .gz opens as a folder, with the same rows, sorting, views and keys as anywhere else, and nothing was added to the app to do it. Zip and gzip ship inside .NET Framework and come in on two framework <Reference> lines rather than packages, so the zero-dependency single-exe build is exactly what it was. Tar is parsed here in about two hundred lines, because System.Formats.Tar is .NET 7 and later while KillerShell targets 4.8.

That reader takes every header flavor in circulation: v7, ustar, GNU long-name records and pax extended headers. pax is what bsdtar, macOS tar and Python's tarfile write by default, so a reader that knows only GNU silently truncates every long path written by anything modern. .rar, .7z, .bz2, .xz, .cab and .iso are neither read nor written; unrar's license forbids reimplementing RAR, so it would mean a dependency to embed.

Why the separator is a question mark

A location inside an archive is one string: the archive's own path, a separator, then the path within it, so a tab, a bookmark and the address bar go on treating a location as a single string. The question mark is the only character that satisfies both rules. It has to be illegal in a Windows filename, or a virtual path could collide with a real file; and it has to be legal to System.IO.Path, because these paths flow through Path.GetExtension all over the app. > and | pass the first and fail the second, so GetExtension throws - which killed every icon inside an archive the first time this was built.

Extraction treats every entry path as hostile. Archive paths are normalized to forward slashes with . and .. segments removed before they reach the browser, and opening an entry deliberately keeps only its leaf filename. That leaf is written inside a new randomly named temporary folder rather than combining the archive's directory path with a destination. A crafted entry such as ..\..\Startup\payload.exe therefore becomes an ordinary payload.exe in KillerShell's temporary extraction area instead of escaping it and overwriting something elsewhere on the machine - the Zip Slip attack.

Changing an archive: zip only, never in place

A .zip is writable: add by drag or paste, rename, delete, New Folder. Tar, .tar.gz, .tgz and .gz are read-only deliberately - the tar reader models regular files and directories only, so a rebuild would silently drop links, devices, FIFOs and sparse members, and a lone .gz holds one unnamed member, so "add a second file" has no representation in the format. A refused write says which refusal it was on the status bar; it never no-ops and never half-writes.

ZipArchiveMode.Update is the obvious route and is deliberately not used: it holds the whole archive in memory while it is open, and rewrites the file in place on save. Every operation instead streams a complete new archive beside the original, proves it reopens with the expected entry count, and only then swaps it in, so a crash, a full disk or a cancel leaves the original untouched. Adding one file therefore rewrites the whole zip, which is why the status bar carries a percentage.

A new archive is a different case. Archive options on the right-click menu adds the selection to a new .zip, .tar or .tar.gz under a name nothing else has, so nothing is replaced. A new tar is written under a temporary name, read back to check it, and only then given its own name.

Out is a copy, by design

Dragging out of an archive is a copy, always. A move out is an extract plus a delete, two steps with no way to make them one, and a failure between them either loses the file or silently leaves it in place; Explorer treats zip drag-out the same way. Dragging a folder out extracts its whole tree, folders and all, wherever you let go.

CLI

The read-only CLI returns JSON for files, search, processes, services, events, registry, drives and SHA-256 hashes. Security-log access requires administrator privileges. An installed copy is on PATH, so it can be run from any new terminal. A portable copy is not, so run it by its file name instead. PowerShell and Command Prompt can return to the prompt before the output appears. To make a script wait, pipe the output, for example killershell --cli drives | Out-String.

killershell --help
killershell --cli list "C:\logs"
killershell --cli info "C:\logs\today.log"
killershell --cli read "C:\logs\today.log" --max-chars 4096
killershell --cli search "C:\logs" --content "error"
killershell --cli processes
killershell --cli services
killershell --cli events System
killershell --cli registry "HKLM\SOFTWARE"
killershell --cli drives
killershell --cli hash "C:\logs\today.log"

The terminal

Running a real shell

Profiles are saved locally and resolved when opened. WSL uses wsl.exe and Bash. Your .bashrc loads first, then KillerShell's editable prompt shows the distribution, folder, and Git status in the current theme. restore_prompt restores your original prompt; KS_PROMPT=0 disables the formatting.

Tracking the working directory

PowerShell and WSL Bash report their folder with OSC 9;9; the parser also accepts OSC 7. Linux paths map to \\wsl.localhost\ for browsing. Custom shells must report their folder to keep the toolbar current.

Finding $PROFILE

The $PROFILE path is obtained by launching the shell binary with -NoProfile -NonInteractive and asking it for $PROFILE.CurrentUserCurrentHost, then validating that what came back is a single rooted path ending in .ps1. Assuming Documents\PowerShell\ instead would be wrong on any machine where OneDrive Known Folder Move has redirected Documents, which on a managed fleet is most of them, and the assumed path is a file the shell will never load.

Prompt glyphs & fallback fonts

The shipped prompt draws powerline separators, a git branch mark and a chevron. No monospaced font Windows ships has any of them, so the exe carries KillerGlyphs.ttf: 26 glyphs, 2,928 bytes, subset from Terminess Nerd Font under the SIL OFL. The renderer asks the font you chose for a glyph and only falls back to that face for the codepoints it does not have, stretching the fallback glyph to the chosen face's cell width so a separator still butts against the next cell. Your font choice is untouched; it just stops being able to fail on those characters. A whole Nerd Font would have cost 2.6 MB, almost all of it icons no prompt draws.

Being the default terminal

Windows' console reads two values under HKCU\Console\%%Startup: DelegationConsole names the console host that serves a console program, and DelegationTerminal names the terminal that shows it. Use KillerShell as the default terminal, in the About card, sets them to Windows Terminal's console host (Stable, Preview or Canary, in that order of preference) and to KillerShell's terminal class, {20CA035E-649B-4288-BB97-19CB0871CD62}. The pair it replaces is saved as DefaultTerminalPrevious under HKCU\Software\KillerShell and put back when the setting is turned off or KillerShell is uninstalled, but only while both values are still KillerShell's, so a choice made since in Settings stays. Only an installed copy can turn it on.

Every install registers that class under Software\Classes\CLSID, in HKCU for one account or HKLM for all users, with LocalServer32 pointing at KillerShell.exe; it does nothing until DelegationTerminal names it. When a console program starts, the console host asks COM for the class, and COM starts KillerShell.exe -Embedding. That process registers the class for a single handoff, receives the program's input and output through ITerminalHandoff3, opens one window and exits when the window closes, so every program gets a process and a window of its own. The window skips the saved session, the quit prompt and the tray. An elevated program can use only the HKLM registration, so it reaches KillerShell from an all-users install. If a handoff fails, or none arrives within 30 seconds, the program stays in Windows' own console window.

The editor

The editor is AvalonEdit, the component behind SharpDevelop, vendored into the repository as source and compiled into the exe rather than referenced as a DLL. That keeps KillerShell a single portable file and costs about 640 KB. The vendored tree was audited to zero compiler warnings on the way in, without suppressing any of them.

Encoding is decided by inspecting the file's bytes, not by the editor's own loader, which hands back a UTF-8 encoding that writes a byte-order mark. Left alone, a plain .txt or .bat would silently grow three bytes at the front the first time it was saved. A BOM that is present is kept, a BOM that is absent stays absent, and bytes that do not decode as UTF-8 fall back to the system ANSI codepage rather than being replaced with U+FFFD. Both the encoding and the line ending are shown under the document, because whether PowerShell 5.1 will read a script depends on both and neither is visible in the text.

Syntax definitions for .bat, .reg, .ini, .yaml, .log and .csv are hand-written and embedded, since AvalonEdit ships none of them. Rather than maintain a repainted copy of every definition for each of the thirteen themes, the shipped colors are run through the same contrast guard the terminal uses: hue is preserved and only lightness is moved, far enough to clear a readable contrast ratio against whatever the current background is. The original color is remembered per definition, so switching themes repeatedly cannot ratchet a color away from what its author intended.

Decoding is strict. A file whose bytes do not decode cleanly in the encoding its mark names, or in UTF-8 or the system codepage when it has none, is not opened, so a save can never change bytes the editor did not understand. A save that the chosen encoding cannot represent is refused rather than written with substitutes. An untitled document, or a file with no extension, takes its syntax definition from its contents, guessed again after each pause in typing.

Processes, storage, performance, events & the registry

Processes & services

Processes/Services (F9, elevated on Ctrl+F9) is one control switching between two grids, not two features bolted together. CPU% is computed as a delta between two TotalProcessorTime samples on a 1.5s tick, not a lifetime average, and command line, executable path and parent PID come from a single bulk Win32_Process WMI query per tick rather than one query per row. Process owner lookups are the expensive part - a per-PID WMI GetOwner() call - so each is done once, cached, and run on its own background thread rather than blocking the refresh; that used to freeze the tab on first load before the lookup was moved off the UI thread. Services mode cross-references ServiceController.GetServices() with a bulk Win32_Service query for the fields ServiceController does not expose, such as start mode, path and log-on account. Every destructive action - end a process, stop or restart a service - goes through the app's own themed confirm dialog, never a stock message box.

Performance monitor

Performance Monitor (F11) reads System.Diagnostics.PerformanceCounter directly: % Processor Time for CPU, with a per-core breakdown, and % Processor Performance for live clock speed; Available, Committed and Free & Zero Page List bytes for RAM; the System category's process and thread counts; % Disk Time and read/write bytes per second per physical disk; bytes sent and received per network adapter; and GPU Engine / GPU Adapter Memory summed the same way Task Manager itself does. Disks and network adapters are enumerated with WMI (Win32_DiskDrive, Win32_NetworkAdapter). GPUs come from DXGI, whose adapter IDs match the GPU counters, so each GPU card reads its own adapter; Win32_VideoController is the fallback. None of them is assumed to be singular. GPU counter instances are rescanned only every 8 ticks instead of every tick, because polling GetInstanceNames() on the GPU categories every second was spamming the Application event log with unrelated Perflib provider-reload errors. Every graph keeps 60 samples of history at a 1s tick, so it always shows the last minute.

Counters are still read once a second. Between samples each readout counts to its new value and each graph slides left, drawn per frame only while the tab is on screen; a tab that is not showing stops sampling. The card arrangement is a single setting, PerformanceLayout, with cards named by stable IDs, so a saved layout still fits when hardware comes and goes.

Storage analyzer

Storage Analyzer (F4, elevated on Ctrl+F4) has two scanners feeding the same treemap. An elevated scan of a local NTFS volume enumerates the Master File Table by file ID and queries sizes directly from the volume, avoiding a path-by-path directory walk. Ordinary accounts, network paths, non-NTFS filesystems, and any MFT failure automatically fall back to the parallel Win32 FindFirstFileEx walker. That fallback drops the unused 8.3-name lookup, carries the \\?\ prefix for long paths, and runs one worker per logical processor. Neither route follows reparse points, and inaccessible entries are counted as skipped rather than making the scan fail.

The map is drawn rather than built. A system drive is easily 200,000 visible rectangles, which is not a number of WPF elements any layout pass survives, so the whole thing is emitted in a single render pass, with the hover and selection rings on a separate overlay layer so moving the pointer never repaints the map underneath. Layout is a squarified treemap, the Bruls, Huizing and van Wijk algorithm, placing children largest first in rows along the shorter side so the rectangles stay close to square and therefore readable and clickable.

The depth and minimum-size controls are view filters applied at draw time, never rescans, which is why they are instant, and neither loses a byte: a folder capped by depth is drawn as one rectangle carrying its whole subtree, and a file hidden by the size floor still counts inside the rectangle of the folder holding it.

Rectangles are colored either by what a file is, from a small table of extension categories painted in the family's neon set with anything unrecognized left gray, so color always means identified, or by which top-level folder of the scan it came from, one hue per branch stepped by the golden angle. Deleting from the map goes through the shell's own Recycle Bin call, so the tab has no permanent-delete path at all, and the map is updated in place afterwards rather than rescanned.

Event Viewer

Event Viewer (Ctrl+F12, always elevated) reads Application, System and Security through System.Diagnostics.Eventing.Reader rather than the older EventLog API, because EventLogQuery can push level filtering into the query itself and read newest-first. Each log is capped at 2,000 records and loaded in batches of 50 on a dedicated long-running thread, since a pooled thread can be reused mid-COM-cleanup and crash. There is no unelevated route to this tab at all: the Security log throws an access-denied error for a standard token, so the tab only exists behind Ctrl+F12.

Registry Editor

Registry Editor (Ctrl+F11, always elevated) is the only one of the five tool tabs with no background thread anywhere, because registry reads are fast enough not to need one. The tree lazy-loads one level at a time with a placeholder-node pattern across all five hives, and Ctrl+F searches key and value names within whatever is already loaded rather than walking the whole registry, which is what real regedit's search does and blocks on. Windows does have a key rename call, RegRenameKey, but on build 26100 it crashed the whole system while renaming a key with protected permissions, so KillerShell never calls it. A rename copies the key's tree under the new name, value types, permissions and child keys included, and deletes the original only once the copy is complete; link keys, and owners a copy cannot keep, are refused. Deleting a key warns, more seriously than the process-kill confirm, that the whole subtree goes with it.

Themes & languages

13 themes, 41 looks: Dark, Light, Black and 98SE each have 8 accent colors. The other 9 have fixed palettes. Switch live without restarting.

The interface is translated into twenty languages and switches live from the globe menu. Any string a translation does not cover yet appears in English.

The whole app also scales. Rolling the wheel over the title-bar wordmark drives a layout transform on the content host, roughly 2% a notch between 70% and 250%, remembered between runs. Because it is a layout transform rather than a render transform, text reflows and re-rasterizes at the new size instead of being stretched as a bitmap, and the title bar and footer stay a fixed size so the wordmark never moves out from under the pointer.

From the keyboard, Ctrl+Shift+Plus and Ctrl+Shift+Minus change the size 5% at a time, and Ctrl+Shift+0 puts it back to 100%.

Glossary

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