$ show valinet/ExplorerPatcher
ExplorerPatcher is a Windows shell customization utility that operates by DLL injection and API hooking inside explorer.exe and related shell processes. In production it ships a patcher DLL (loaded via a dxgi.dll stub renamed into the Explorer directory), a settings GUI (ep_gui.dll, launched via rundll32 dxgi.dll,ZZGUI), an installer/uninstaller (ep_setup.exe), a WebView2-based weather COM host, an Alt+Tab replacement module, and a Start menu patching module (ep_startmenu). At runtime it reads feature toggles from HKEY_CURRENT_USER\Software\ExplorerPatcher, hooks undocumented internal COM interfaces and WinRT activation factories, applies inline machine-code patches and vtable replacements, and restores Windows 10 taskbar, Start menu, context menus, and Alt+Tab behaviors on Windows 11. It also downloads symbols from Microsoft symbol servers and uses byte-pattern scanning to resolve version-specific function offsets. Architecturally this is a suite of loosely coordinated native Windows modules rather than a monolith: the core patcher coordinates them, a chainloader (ep_extra.dll) discovers and loads ep_extra_*.dll plugins, and everything is versioned and bundled by the setup program using AES-encrypted embedded ZIP resources. External dependencies include KNSoft.SlimDetours for hooking, Microsoft WIL, WebView2, zlib, libvalinet, SimpleWindowSwitcher, plus git submodules and a separately downloaded ep_taskbar.dll. The code is heavily build-specific, with x64/ARM64/IA-32 branches and fallback pattern sets for Windows 10/11 builds from 22000 through current 26100+ servicing builds. The craftsmanship is genuinely notable for a reverse-engineering project: ARM64 instruction encode/decode helpers, multi-stage pattern scanners with gap and bitmask variants, SlimDetours transactional IAT hitching, and clean reusable header templates for allocation policy strings and COM ref-counting. The maintenance burden is inherent and huge — every Windows cumulative update risks breaking hardcoded offsets, and the code carries architectural debt from this fight: monumental C files (dllmain.c exceeds 4000 lines), heavy preprocessor branching, dead #if 0 blocks, and no automated test suite. It is not a data/research repository despite containing bundled .pri and .mui localization assets; those are deployment resources, not data artifacts. Despite its fragility, the project tracks Windows updates aggressively (weekly fixes per the changelog) and delivers a working, widely deployed product.
The LLM identified 5 files worth highlighting for reuse:
A self-contained, single-header C++ template implementing a reference-counted COM object base. It encapsulates AddRef/Release/QueryInterface boilerplate behind a generic template, is decoupled from the rest of the codebase, and can be dropped into any native Windows COM/WinRT C++ project to eliminate repetitive ref-count plumbing.
A C++ string class parameterized by memory allocation policy (CoTaskMem, LocalAlloc, HeapAlloc, GlobalAlloc). This allocator-policy design is portable and generic: any Windows C++ project that must hand strings across COM/Shell APIs with different ownership rules can extract this header and use it unchanged. It demonstrates non-obvious craft in bridging STL-style ergonomics with Win32 allocation conventions.
A library of byte-signature scanning routines (FindPattern, FindPattern_4_, bitmask variants) plus ARM64 instruction decode/encode helpers (ARM64_DecodeADRL, ARM64_DecodeADD, ARM64_FollowBL, etc.) used to locate and rewrite function prologues across Windows builds. The functions operate purely on supplied buffers and patterns with no internal-module coupling, making them directly extractable into any binary analysis, security tooling, or RE framework that needs resilient x64/ARM64 signature scanning.
A generic registry-change monitoring subsystem built on RegNotifyChangeKeyValue with a dedicated watcher thread and per-key callback dispatch. The pattern is transportable beyond ExplorerPatcher: any Windows application that needs live configuration reload from the registry (or filesystem via the same notification idiom) can reuse this design with minimal adaptation. It is one of the few modules in the repo cleanly separated from the patching logic.
A self-contained implementation of the POSIX fmemopen() function for Windows, including the supporting getline.c shim. It is a classic portable-utility pattern: pure C, no internal repo dependencies, and directly reusable in any cross-platform or Windows-only project that needs in-memory stream semantics. Demonstrates disciplined reimplementation of standard libc behavior rather than the usual Windows-console workaround.