Inspiration
NeeView is an image viewer designed for browsing images stored in folders and compressed archives. It already includes its own file search, but users with large collections may also use Everything, a Windows application specialized in quickly locating files by name.
NeeView-EverythingSearch was created to connect these two tools. The goal was to let NeeView use Everything when it is available, without removing or replacing NeeView’s original search system. The project is an unofficial derivative of NeeView and is not endorsed or maintained by either the original NeeView developer or voidtools. Everything is also not bundled with the application and must be installed separately.
What it does
NeeView-EverythingSearch adds an optional Everything-powered search path to the folder list in NeeView’s bookshelf interface.
When a compatible Everything process is running, NeeView can send a search request to it and receive a list of matching file paths. When Everything is not running, cannot receive the request, does not support the search condition, or returns an error, the application falls back to NeeView’s standard search.
This means the Everything integration acts as an optional shortcut rather than a required part of the application. NeeView can still start and search files without it.
How we built it
The project communicates with a locally running Everything process through its public IPC interface using the Windows WM_COPYDATA protocol.
The search system was divided into separate providers. One provider uses Everything, while another keeps the original NeeView search behavior. A selection layer decides which provider can safely handle each request.
The implementation also includes timeouts, cancellation handling, Unicode path support, result parsing, and fallback behavior. Tests were added for empty results, large result sets, Japanese file names, missing IPC windows, malformed responses, timeouts, cancellation, and unsupported search conditions.
The public repository also includes a Windows-based GitHub Actions workflow, documentation, and a PowerShell script for producing a portable release package.
Challenges we ran into
One major challenge was making sure that the new search path could fail safely. Communicating with another application introduces several possible problems: Everything may not be running, its IPC window may not be available, a reply may never arrive, or the returned data may be invalid.
Another challenge was preparing a personal modification for public distribution. The development environment contained local history, profiles, bookmarks, settings, backups, generated ZIP files, and machine-specific information that should not be published.
To address this, a clean public branch was created from an upstream NeeView commit. Only the required feature changes, tests, documentation, CI configuration, and publishing tools were reapplied. Personal data, local artifacts, Everything binaries, and private development files were excluded and scanned before release.
Accomplishments that we're proud of
The project preserved NeeView’s standard search while adding an isolated Everything-based provider with timeout, cancellation, and fallback handling.
During the final pre-publication verification on July 9, 2026, the Release/x64 build completed with zero warnings and zero errors. The unit test run reported 131 passed tests, with zero failures and zero skipped tests.
A public repository and an initial pre-release, v0.1.0, were created. The release included a Windows x64 ZIP package and a SHA-256 checksum file. The release package was also checked for personal profiles, bookmarks, history, Everything binaries, nested installers, logs, secrets, and machine-specific information.
What we learned
We learned that adding a feature and publishing a reliable application are separate tasks.
The search feature itself required careful handling of errors and unsupported conditions. Public distribution required additional work involving tests, documentation, licensing, privacy checks, reproducible builds, release packaging, and checksums.
We also learned the importance of keeping project instructions and progress inside the repository. AGENTS.md defines the project rules, PUBLISHING_ROADMAP.md records the planned work, and PUBLISHING_STATUS.md records completed commands, test results, and remaining risks. This makes it easier for both people and development tools to understand what has been completed and what still needs verification.
What's next for NeeView-EverythingSearch
The next steps are focused on real-environment verification rather than adding more features.
The project still needs testing on clean Windows 10 and Windows 11 environments. The fallback behavior should also be tested through the actual user interface while Everything is stopped or IPC is disabled.
Additional compatibility checks are needed for Everything Lite and named Everything 1.5 instances. Differences in result ordering and edge cases between Everything search and standard NeeView search also need to be documented with repeatable examples.
A final human review of the added code’s origin and licensing remains necessary. The repository also does not contain a repeatable performance benchmark, so no specific search-speed improvement can currently be claimed.
Log in or sign up for Devpost to join the conversation.