DEV Community: yyzTools

You Can Write Desktop Tools in Plain HTML/CSS/JS — Here's the SDK That Lets You

yyzTools — Mon, 07 Sep 2026 02:36:52 +0000

I build yyzTools — a free, local-first Windows productivity suite (command palette, clipboard history, OCR, file preview, batch processing — 40+ tools in one install). Today's post isn't about the app itself; it's about the module SDK I just opened up, because the development model is the kind of thing frontend developers keep telling me should be impossible: **one static webpage + one JSON file = a native desktop tool window.* No C++. No build step. No packaging.*

The demo first

Download the sample project, unzip it, and you get two folders — Web/ and Modules/. Copy them next to yyzTools.exe, restart, and hit Alt+Space. Type sdk:

A 760×540 native window opens. It's a full-disk file search app — instant results, Everything-style syntax (ext:pdf size:>100mb), double-click to open files.

Behind that window:

Web/SDK_Sample/
  index.html       # plain DOM, data-i18n attributes
  filefinder.js    # all the logic (vanilla JS, zero deps)
  filefinder.css   # styled entirely with --zen-* variables
  i18n.js          # string dictionary (zh_cn / en)
  lib/
    zen_api.js     # the ONLY library — the native API wrapper
Modules/SDK_Sample.zenmod   # one JSON declaring the window

No package.json. No node_modules. No bundler. It's 2026 and I'm shipping an SDK whose sample runs without a toolchain — deliberately, and the reason matters.

How the window gets born: it's declared, not built

The part of desktop development that scares everyone off was never business logic — it's windows. Message loops, DPI awareness, taskbar integration, hotkey registration. The SDK's answer is to make the host a data file:

{
    "id": "sdk_sample",
    "type": "web",
    "url": "SDK_Sample/index.html",
    "width": 760,
    "height": 540,
    "layoutType": 34,
    "icon": "fas fa-search"
}

The host reads this at startup and creates a native window with a WebView2 control pointing at your page. And because the module now exists in the app's registry, it inherits the whole suite's infrastructure for free:

Command palette search — localized across all 12 UI languages
Global hotkey binding
Dock mounting
Theme integration — the host injects --zen-* CSS variables; your page follows the app's light/dark mode with zero prefers-color-scheme media queries

You write the feature. The host absorbs the decade of Win32 plumbing.

## Talking to the system: the ZenAPI bridge

Your webpage gets system powers through a window.Zen bridge, consumed via an official ZenAPI wrapper class:

import ZenAPI from './lib/zen_api.js';

// Full-disk search (async — runs on a background thread)
const res = await ZenAPI.searchFile('invoice ext:pdf', 200);
if (!ZenAPI.isOk(res)) { /* unified error check */ }

// Open the file / reveal in Explorer
await ZenAPI.openFile(fullPath, false);
await ZenAPI.openFileLocation(fullPath);

// Persist your own config (narrow-grained patch, not full rewrite)
await ZenAPI.setConfig({ sdk_sample: { history } });

One design detail worth stealing for anyone building a JS bridge: searchFile is asynchronous, and the native side implements a search slot — a new request displaces any in-flight one (the old Promise resolves empty). Combined with 300ms input debounce and a monotonically increasing sequence number on the frontend to discard out-of-order responses, rapid typing neither floods the background thread nor flashes stale results. In interactive search, the correct semantic for concurrent requests is overwrite, not queue — the opposite of what server-side intuition tells you.

The API surface goes well beyond search: file dialogs, chunked reads for large files, clipboard, screenshot → OCR pipeline, spawning external programs, invoking other module windows. The full reference is published in 12 languages — including which interface returns isDir as a 1/0 number rather than a boolean, because hand-rolled JSON paths and property-tree paths serialize differently. Documenting the type traps is the difference between docs people trust and docs people tolerate.

Debugging: just open it in a browser

This is the part that sells frontend developers. Double-click index.html — it opens in your normal browser. There's no window.Zen there, so ZenAPI.call goes down the exception path and returns error: -1, but your layout, styles, debounce, and rendering logic all work normally. Iterate the UI in the browser; hop into the real host only for native integration. The degradation path was designed in from day one.

The honest security section

The native API is fully open to module developers: file read/write/delete, process creation, window control, clipboard. No permission prompts, no sandbox, no undo.

That's a trust-model decision, not an oversight. This SDK targets developers building tools for themselves or their team — the deployment unit is "copy a folder", the distribution radius is people who already trust you. If an attacker can write to your modules directory, they can already drop an exe; disguising it as a .zenmod gains them nothing. Sandboxing buys you nothing here and costs every module author a permissions negotiation they don't need.

If I ever build a public module store, this design gets rebuilt — different trust model, different security requirements. Match the security to the trust model, not to a checklist.

Why bother

If you write web pages at all, here's the pitch: your existing skillset now produces desktop tools with a native window, global hotkeys, tray integration, and a theming system — for the cost of one folder and one JSON. The internal tool you'd otherwise ship as "open this localhost link" can be a real window in the palette.

Docs (quick start + full API reference): yyztools.com/sdk.html
Sample project download: same page
The app: free forever, no accounts, no telemetry, Windows 10/11

The sample is a genuinely pleasant read — four files, an hour, including the debounce/race handling. If you build something with it, drop it in the comments; good ones may make it into the built-in catalog.

The Local-First Tax: What It Actually Costs to Refuse the Cloud

yyzTools — Thu, 03 Sep 2026 13:03:38 +0000

I'm building yyzTools — a Windows productivity suite (clipboard history, OCR, file search, app usage stats) that is aggressively local-first by design. No accounts, no telemetry, no cloud sync. This post isn't about the product. It's about the real costs of the stance.

The pitch vs. the tax

"Local-first" is a compelling pitch: your data stays on your machine, no cloud dependencies, no breach exposure, works offline. It resonates with privacy-conscious users and with developers who've seen what happens when a cloud service sunsets your data.

But the pitch hides real costs. After building a local-first tool for years, here's the tax I've paid—and what I'm still not sure is worth it.

The costs

1. Multi-device sync is genuinely gone

"Copy something at work, see it at home" is the cloud clipboard's killer feature. I can't offer it without violating the core principle (data leaves the machine). My users—and I—work around it by manually syncing the local storage directory with a file-sync tool.

That feels like 2005. The cloud clipboard isn't popular by accident; cross-device sync is genuinely useful. Telling users "just sync the DB folder yourself" is a real regression in convenience.

2. Local models are heavy

The OCR engine (RapidOCR's ONNX models) ships in the installer. The app is ~600MB. A cloud OCR tool is a 5MB app + a server. Users with small SSDs or slow connections notice.

There's no way around this with local-first: a capable local model has weight. The trade is "data stays local" for "installer is large." I've made peace with it, but it's a tax.

3. No network effects

Cloud tools get sticky because your data is there, your collaborators are there, your history is there. A local tool has none of that. Retention is purely "does this work well enough day to day?"—which is fragile. A user can walk away any time, taking nothing with them.

For a solo dev without a marketing budget, this is a slow grind. Cloud tools compound (data lock-in); local tools don't.

4. The convenience/privacy framing is mostly a false binary

"People will trade privacy for convenience" is the industry line. In my experience, users don't perceive the trade at all. They hit "allow" and use the cloud tool. The local-first stance is invisible until something goes wrong (a breach, a policy change, a sunset), at which point it's too late—the data is already gone or compromised.

You're selling insurance against a low-probability event. Most users don't buy insurance they can't see.

5. The user is responsible for backups

Cloud tools hide backup responsibility. Local-first puts it on the user. I document the storage path and recommend syncing it, but I can't force it. If a user's drive dies and they didn't sync, their clipboard history is gone.

This is philosophically correct ("it's your data, you own the responsibility"), but operationally it's a support burden and a UX cliff.

Where I drew the line

Not everything can be local. Translation, downloads, opening URLs—these are network by nature. The question is how to handle the network features honestly.

My rule: the network feature's data destination is explicit and user-chosen. Translation sends data to the service the user picks in settings (DeepL, Google, etc.), not a fixed yyzTools server. The user knows where their text goes because they chose the service. No hidden relay.

This is a middle path: local-first for the data that can be local (clipboard, OCR, search, stats), explicit-and-chosen for the data that can't (translation). It's not pure, but it's honest.

The no-account stance

Accounts aren't just "friction." They're a privacy design decision:

Account → behavior tied to identity → you're processing personal information, with all the compliance that implies
No account → no identity → behavior can't be linked to a person → no personal information processing

yyzTools has no accounts, no telemetry, no behavioral collection. This isn't "saving a registration step"—it's a structural choice that removes the possibility of identity-behavior linkage. For users in regulated environments (enterprise, healthcare, government), this is a feature, not a limitation.

For personal users, it's invisible. Nobody installs a clipboard manager thinking "glad there's no account." They notice the absence only when a cloud tool's breach headlines hit.

Is it defensible?

I keep going back and forth.

The case for: privacy regulations are tightening (GDPR, data residency laws). As breaches accumulate and cloud trust erodes, the local-first stance ages into relevance. The users who care are a minority, but they're loyal. The stance differentiates in a market where "free + cloud + ads" is the default.

The case against: 95% of users don't value it until it's too late. The convenience tax (no sync, large installer, no collaboration) is felt daily; the privacy benefit is felt never (until a breach, which probably won't happen to them). You're paying a real daily cost for an insurance most users will never collect on.

I don't have a conclusion. I have a stance and a tax bill, and I'm still calculating whether the exchange is worth it.

What I actually want to ask

I'd love to hear from both sides:

For users who've tried local-first tools and reverted to cloud: what was the breaking point? Sync? Collaboration? The lack of a web UI?
For users who run local-first and wouldn't go back: what makes it worth the convenience cost for you?
For builders: is local-first a defensible long-term position, or a boutique stance that 95% of users don't value? Does it only make sense in regulated industries, or is there a broader market?
The middle path—local for what can be local, explicit-chosen cloud for what can't—is it meaningfully different from a cloud tool, or just a cloud tool with better labeling?

I'm not here to sell you on local-first. I'm here because I'm honestly uncertain whether it's a defensible position or a philosophical luxury, and I'd value outside perspective.

I'm building yyzTools — a free, local-first Windows productivity suite. No accounts, no telemetry, no cloud sync. Website: yyztools.com. The "no sync" tax is real; I use a file-sync tool myself.

Why I Replaced Everything With a Homegrown MFT Search Engine (Memory: Hundreds of MB a Few MB)

yyzTools — Wed, 02 Sep 2026 13:21:47 +0000

I build yyzTools — a free, local-first Windows productivity suite that folds 40+ tools (command palette, clipboard history, OCR, file preview, batch processing) into one installer. This post is about the 1.0.5 release, where I did something that sounds insane: I removed my dependency on Everything — the gold standard of Windows file search — and wrote my own engine.

The setup

For about two years, file search in yyzTools was powered by Everything. And let me be clear: Everything is phenomenal. Sub-second full-disk search, a mature query syntax (ext:pdf size:>100mb dm:today), battle-tested by millions of users. Integrating it was one of the best decisions I made early on — instant world-class search for free.

But there was a catch that grew more annoying with every release: Everything is designed to be used standalone. Its index lives in its own service process. On a machine with a lot of files, that index holds hundreds of MB of RAM, resident from boot to shutdown.

For a standalone search tool, that's a perfectly reasonable price. But yyzTools is a resident suite — the whole point is that it sits quietly in your tray until you hit Alt+Space. Every MB of resident memory lowers the threshold at which users uninstall you. And search is the heaviest feature in the suite.

So the conflict was structural: the dimension Everything optimizes least for (being embedded in someone else's memory-sensitive app) was exactly my core requirement.

In 1.0.5, I replaced it. Index memory went from hundreds of MB to a few MB. Query syntax stayed Everything-compatible. Here's how.

Wrong turn #1: the "official" API is a trap

When you start researching full-disk enumeration on Windows, you find FSCTL_ENUM_USN_DATA. Documented, blessed, gives you every file's FRN (file reference number) and parent FRN. Seems like the obvious choice.

I implemented it. 1.34 million files, 120 seconds to enumerate. Rejected.

The problem: USN records are a change journal, not a catalog. They don't carry file size or timestamps — so for every single file you have to call back with FSCTL_GET_NTFS_FILE_RECORD to fetch the full MFT record. A million random reads by FRN. That's not slow code; that's a wrong-shaped data channel.

The Everything way: read $MFT directly

Everything and WizFile don't use that API for full enumeration. They open the volume device (\\.\C:, read-only) and read the $MFT byte stream directly. The Master File Table is NTFS's census book: every file and directory is one fixed 1024-byte record, stored sequentially, containing name, size, and timestamps. Scan it linearly and you get everything in one pass of sequential IO:

// 1. Parse the $DATA run list of $MFT's own record (VCN→LCN mapping)
static bool ParseMftRuns(BYTE* mftRec, int len, std::vector<int64_t>& lcns, ...);

// 2. ReadFile the volume handle in chunks, per run
// 3. Fix up each 1024-byte record, extract $FILE_NAME / $DATA attributes

Two details worth knowing if you go this route:

Hard links: one MFT record can carry multiple $FILE_NAME attributes (one per link, each pointing at its own parent directory). Each one must become a separate row in your index, or link results silently go missing.
Permissions: reading the volume device needs more than a standard user token. That's why the engine runs as a separate process backed by a Windows service — the service holds the volume handle, the main app consumes queries over IPC, and the GUI never elevates.

Where the memory went: columnar storage

The full-enumeration part was honestly the easier half. The interesting question was: you now have 1.34 million rows of metadata. How do you hold them in RAM for a few MB instead of a hundred-plus?

The naive layout is an array of objects:

struct FileEntry {
    uint64_t frn, parentFrn, size;   // 24 B
    int64_t  mtime;                 // 8 B
    std::string name;               // 32 B + heap allocation per file
    bool isDir;                     // 1 B + 7 B padding
};

Padding, per-string heap allocations, allocator headers, terrible cache locality. That's your hundred-plus MB right there — not because anyone wrote bad code, but because the layout itself is that size.

The engine stores rows columnar instead — separate tight arrays, one per attribute, plus an interned name pool:

std::vector<uint64_t> frns;      // full 64-bit FRNs (sequence<<48 | index)
std::vector<uint64_t> sizes;
std::vector<uint32_t> mtimes;     // Unix seconds — 1970..2106 fits in 4 bytes
std::vector<uint32_t> nameOffs;   // offset into the blob
std::vector<uint32_t> nameLens;
std::vector<uint8_t>  isDirs;
std::vector<char>     nameBlob;   // UTF-8 pool, no NUL terminators, deduplicated

Every frontend developer knows this instinctively: it's the difference between [{name, size, mtime}, ...] and one TypedArray per column. SoA beats AoS when you scan.

The merciless details that stack up:

Interned names. "New folder", "package.json", "index.js" appear tens of thousands of times each. One copy in the blob; every row is just an 8-byte offset+length slice.
uint32 Unix-seconds mtimes. Halves the time column; 1970–2106 is plenty.
Lowercase names that aren't there. Case-insensitive search needs a lowercased name — but most filenames are already lowercase. Each row carries a flag bit: if the folded name is byte-identical to the original, the lowercase view just reads the original blob. Saves nearly an entire second name pool.
Derived columns aren't persisted. The parent FRN you need for path reconstruction is derivable from the parent-row column at query time, so the snapshot simply doesn't contain it.

Same data, different layout: hundreds of MB becomes a few MB. Structure, not optimization.

Staying fresh: USN journal catch-up — and a subtle trap

Full builds are one thing; filesystems keep changing. NTFS ships a change journal (USN records, monotonically increasing). The engine stores an anchor (JournalId, NextUsn) and periodically replays new records.

The trap I hit so you don't have to: the anchor must be taken before enumeration starts, not after it finishes.

My first version grabbed the current USN after the full scan — logically airtight, right? Wrong. The scan takes seconds. Save a file during the scan and it may not be on disk when your read passes its directory, yet its USN is already below your anchor. The journal replay skips it forever. The index is silently missing a file, no error, no recovery.

Store the pre-enumeration anchor. Replay may redundantly re-apply a change that the scan already caught — idempotent, harmless. Missing is not.

Also: journals get trimmed and recreated. The anchor's JournalId detects that; on mismatch, abandon incremental catch-up and do a full rebuild. Correctness always outranks cleverness.

Persistence: mmap snapshots

Rebuilding on every boot is wasteful, so the index snapshots to disk per volume and loads via mmap — O(1) open, column pointers point straight at mapped pages, zero copies. The query-accelerating structure (an ASCII bigram inverted index, VByte-delta compressed) is materialized into the snapshot, so loading requires zero rebuilding.

Two Windows-specific footnotes for anyone doing this:

After mmap-loading, call PrefetchVirtualMemory. Otherwise the first full scan pulls tens of MB in random 4 KB page faults (measured: ~6 s on my C: volume) while the OS pages things in lazily.
A file you have mmap'd cannot be replaced. Atomic snapshot replacement (MoveFileEx over the old path) fails with gle=5 while your own process still holds a mapping of the old file — even though you're "just" swapping the path. Release your own mapping first, and guard the column-pointer swap with a reader-writer lock so in-flight queries don't race the swap.

The scorecard

	Bundled Everything	Homegrown (1.0.5)
Index memory	Hundreds of MB (external service)	A few MB
External dependency	Third-party install/bundle	None
Query syntax	Everything's	Compatible (`ext:pdf`, `size:>100mb`, `dm:today`)
Control	Black box	End-to-end

Was it worth it? For this product, yes — search is the palette's core experience, and resident memory is the metric that decides whether a tray app survives on someone's machine. The rule of thumb I'd offer from this round:

Don't build a wheel where the existing one is already optimized for you. Build it when your core requirement is exactly the dimension the dependency doesn't optimize for.

Everything is perfectly optimized for being Everything. It was never going to be optimized for being inside something else.

This shipped in yyzTools 1.0.5 — free, no accounts, no telemetry, Windows 10/11, at yyztools.com. The same release also added a quick OCR-translate pipeline (screenshot → recognize → translate, all offline via the local RapidOCR engine). Happy to dig deeper into any part of this in the comments — the parallel-scan worker pool has a genuinely fun stack-lifetime crash story if anyone wants it.

yyzTools: 40+ Windows Productivity Tools in One Install — Local-First, Free Forever

yyzTools — Wed, 02 Sep 2026 13:14:35 +0000

Tired of juggling a dozen separate utilities — a launcher, a clipboard manager, a translator, an OCR tool, a file previewer, a screenshot app, a batch renamer...? yyzTools fuses them all into a single, native Windows application with a shared data layer and unified keyboard shortcuts. No plugins. No accounts. No telemetry.

The Problem

If you're a Windows power user, your efficiency toolkit probably looks something like this:

Need	Typical tool
App launching	PowerToys Run / Flow Launcher
File search	Everything
Clipboard history	Ditto / Windows built-in
Translation	DeepL + browser extension
OCR	Online tool / Umi-OCR
File preview	QuickLook
Screenshots	Snipaste
Batch renaming	Separate utility
JSON formatting	Browser tab
Regex testing	regex101.com
Base64 encoding	Browser tab

Each tool has its own shortcut, its own settings panel, its own update channel — and crucially, none of them talk to each other. You can't pipe clipboard history into OCR, or send OCR output directly to translation, or push translation results back to the clipboard. Every cross-tool workflow requires manual copy-paste intermediation.

The Solution

yyzTools (Yes Your Zen Tools) takes a different approach: fuse 40+ productivity tools into a single install, sharing one data layer, one set of keyboard shortcuts, and one visual language.

Current version: v1.0.3.1300
Platform: Windows 10 1809+ / 11, 64-bit
Price: Free forever, no account required
Languages: 12 (English, Simplified Chinese, Traditional Chinese, Japanese, Korean, French, German, Spanish, Russian, Arabic, Portuguese, Italian)
Website: yyztools.com

Architecture: C++ + WebView2

yyzTools uses a hybrid architecture that's worth understanding as a developer:

┌─────────────────────────────────────────┐
│     Frontend (Alpine.js + vanilla JS)   │
│   cmdplate / ocr / translate / ...      │
│   Unified via web/lib/zen_api.js        │
├─────────────────────────────────────────┤
│      WebView2 Bridge Layer              │
│   BindSync → synchronous return          │
│   BindAsync → async callback (OCR only)  │
├─────────────────────────────────────────┤
│         C++ NativeApi Layer              │
│  FileManager / ProcessManager /          │
│  ClipboardManager / OcrManager /        │
│  DownloadManager / CmdManager ...        │
├─────────────────────────────────────────┤
│            Win32 System API              │
└─────────────────────────────────────────┘

Key design decisions:

WebView2 over Electron: Uses the Windows-built-in Edge engine, no bundled Chromium, lower memory footprint
Alpine.js (3KB) over React/Vue: No virtual DOM overhead, no heavy build chain
Vite multi-entry: Each feature page is an independent bundle
Frontend updates without recompiling C++: UI changes ship as frontend dist, no .exe rebuild needed

The JS ↔ C++ bridge is straightforward:

// Frontend calls go through ZenAPI wrapper, never raw window.Zen
class ZenAPI {
    static isOk(res) {
        return String(res.error) === '0';  // Normalizes both number 0 and string "0"
    }
    static async getConfig() {
        return await window.Zen.getConfig();
    }
}

// C++ registration in NativeApi::SetupBindings()
m_bindManager->BindSync("getConfig", [this]() { return this->GetConfig(); });
m_bindManager->BindAsync("ocrRecognition",
    std::bind(&NativeApi::OcrRecognition, this, _1, _2));

All methods return a JSON object { error, errorMsg, ... }. error === 0 means success.

Core Features

Command Palette — One Search Box for Everything

Alt + Space brings up the unified entry point. Prefix-based domain switching:

Prefix	Searches	Replaces
(none)	Apps, system commands, settings, command modules	PowerToys Run
`f`	All files (Everything SDK)	Everything
`p`	Running processes	Task Manager
`w`	Windows	—
`b`	Browser bookmarks	—
`c`	Clipboard history	Ditto
`>`	Command line	Terminal

Also includes instant math: type 128*0.85 or sqrt(144)+3^2 and the result appears in real-time, press Enter to copy.

Supports pinyin search for Chinese app names — typing weixin or wx finds WeChat.

Clipboard History + Cross-Feature Pipeline

Text and image clipboard history with:

Pin images to desktop as floating windows (great for reference screenshots)
Pipeline: select a text entry → send to translation; select an image → send to OCR

This is the "fusion" advantage — no manual copy-paste between tools.

Local OCR (RapidOCR)

Screenshot-to-text using the local RapidOCR engine:

Fully offline — no cloud API, no upload, no latency
Chinese-English mixed recognition
Pipeline: Screenshot OCR → one-click translate → one-click copy to clipboard

File Preview

Spacebar to preview without launching any app:

Word / Excel / PowerPoint / PDF
Images / Videos / Audio
Code files (syntax highlighted)
Archive files (browse directory tree)
DXF drawings

Developer Tools

Built-in utilities that replace browser tabs:

Tool	What it does
Regex tester	Real-time match highlighting, group viewer
Encode/Decode	Base64 / URL / HTML / Unicode / Hex / Morse
Hash calculator	MD5 / SHA-1 / SHA-256 / SHA-512 for text and files
Crypto	OpenSSL-based symmetric/asymmetric encryption, key generation
Data conversion	JSON ↔ YAML ↔ XML ↔ TOML ↔ CSV, hex/case/width conversion
Data generation	UUID v4, ULID, random strings, batch test data

Batch Processing — Three Heavy-Duty Engines

Engine	Powers	Capabilities
ImageMagick	Image batch	Resize, crop, format convert, watermark, compress
FFmpeg	Video batch	Transcode, trim, extract frames, compress, extract audio
pdfcpu + Ghostscript	PDF batch	Merge, split, watermark, compress, encrypt/decrypt

Plus a batch rename tool with preview: sequential numbering, find-replace, regex, case, EXIF date.

Screenshots + Recording

Region screenshot: Select area, copy or save
Scrolling screenshot: Scroll to capture long pages/documents
Pin to screen: Pin screenshots as desktop sticky notes
Screen recording: Record screen + audio, optional webcam overlay, auto zoom-follow on mouse, keystroke display, one-click export

Command Module System (.zenmod)

379 built-in command modules across 5 categories:

Category	Count	Examples
System	257	All Windows Control Panel functions
AI Tools	55	ChatGPT, DeepSeek, Gemini, Claude, Qwen, etc.
Apps	47	Volume control, shutdown, screenshot, etc.
Internal	21	Translation, OCR, download, calculator, etc.
Web	2	OneNote, Microsoft To-Do

Extending is trivial — drop a JSON file into the Modules/ directory:

{
    "id": "my-tool",
    "type": "app",
    "name": { "en": "My Tool", "zh_cn": "我的工具" },
    "desc": { "en": "Quick launch", "zh_cn": "快速启动" },
    "cmdPath": "yyzBrowser.exe",
    "cmdArgs": "--url=https://example.com --size=800x600"
}

No compilation, no restart. The command appears in the palette immediately.

Dynamic Wallpaper + Desktop Effects

Windows Composition API places web pages and videos below the desktop icon layer — no icon obstruction, no click interference. Game mode pauses all effects to free resources.

Design Philosophy

Local-First

All data processed locally:

Clipboard history → local storage
OCR → local RapidOCR model, no cloud API
File search → local Everything index
App usage stats → local records
File preview → local parsing

Only translation (calls translation service API) and update checks require network.

Free Forever

No paywalls, no premium tier, no trial countdown
No account registration required
No identity collection, no user profiling, no behavioral telemetry
No ads

Delta Updates

Each component (main binary, frontend pages, command modules, FFmpeg, OCR models) is packaged independently. Updates download only the changed sub-packages — a frontend-only update might be a few hundred KB, not a full 1GB reinstall.

Comparison

	yyzTools	PowerToys	uTools	Flow Launcher
Architecture	C++ + WebView2	C# + WPF	Electron	C# + WPF
Feature source	All built-in	All built-in	Plugin market	Plugin market
Translation	Built-in	None	Plugin	Plugin
OCR	Built-in (offline)	None	Plugin	Plugin
Batch processing	ImageMagick/FFmpeg/pdfcpu	None	Plugin	None
File preview	Office/PDF/code/archive	SVG/PDF/MD	Plugin	None
Data pipeline	Clipboard→OCR→Translate→Copy	None	No shared data layer	None
Extension method	JSON file (zero compile)	C# plugin	Plugin market	C# plugin
Price	Free	Free	Paid tier	Free

The key difference isn't feature count — it's integration. yyzTools features share one data layer and can pipe into each other. The others are either loose collections of independent tools (PowerToys) or plugin platforms where plugins don't share state (uTools).

Getting Started

Download: yyztools.com
Requirements: Windows 10 1809+ / 11, 64-bit
Cost: Free, no registration
Languages: 12 (English, Chinese Simplified/Traditional, Japanese, Korean, French, German, Spanish, Russian, Arabic, Portuguese, Italian)

Quick start:

Download and install from yyztools.com
Press Alt + Space to open the command palette
Type a feature name or app name to search
To add custom commands, drop a .zenmod JSON file into the Modules/ directory

If you use 3+ of the tools yyzTools covers (clipboard manager, translator, OCR, file previewer, batch renamer, screenshot tool, regex tester, etc.), it's worth trying as a single replacement rather than maintaining a fragmented toolkit.

Website: yyztools.com · Free forever · Local-first · 12 languages

Shipping Stock CLIs as Subprocess Instead of Static-Linking SDKs

yyzTools — Sun, 23 Aug 2026 06:30:53 +0000

I'm building yyzTools, which bundles 9 third-party engines (OpenSSL, FFmpeg, ImageMagick, pdfcpu, Aria2, 7-Zip, RapidOCR, Everything...). I chose to spawn them as subprocesses rather than static-link their SDKs. Here's why—and the cost.

The conventional approach
When your app needs OpenSSL crypto, FFmpeg video processing, ImageMagick image ops—you reach for the SDK. Link libssl, link libav*, link libMagick. One binary, no external deps, fast function calls. It's the textbook answer.

I did the opposite. yyzTools ships the stock CLI binaries (openssl.exe, ffmpeg.exe, magick.exe, pdfcpu, aria2c, 7z) and spawns them as subprocesses. The C++ layer is a thin loop: build args → CreateProcess → read stdout → wrap as JSON → return. It doesn't know what -gravity southeast or sm4-cbc means. It just passes the algorithm name through.

Why I went this way

Upgrades without recompiling This is the big one for a desktop app. OpenSSL ships a CVE, or adds sm2/sm3/sm4 support in 3.x. If you've static-linked, you recompile the whole app, run full regression, re-release, and every user reinstalls.

With the subprocess model, I drop in a new openssl.exe. Zero C++ changes. The update is a few-MB delta, not a full reinstall. For a product where users won't tolerate reinstalling for a library bump, this is the deciding factor.

No symbol conflicts
OpenSSL, zlib, libpng—multiple libraries want to own these symbols. Static linking them all into one binary is a recipe for "which inflate did I just call?" With subprocess CLIs, each tool brings its own dependencies in its own process. No conflict.
Transparent supply chain
openssl version, ffmpeg -version—auditing which version of each tool is live is trivial. It's an independent binary. Far easier than digging symbols out of a statically-linked blob.
Free crash isolation
If ffmpeg.exe misbehaves, it exits non-zero and my host wraps that as an error. My main process keeps running. A static-linked bug can take down the whole app. The process boundary is a free fault domain.
Algorithm support is "front-end list + docs", not C++ rebuild
Because the C++ side just passes algorithm names through, adding a new hash algorithm means adding a line to the front-end's ALGORITHMS list and updating docs. NativeApi doesn't change. I covered sm2/sm3/sm4 in a day this way.

The cost
This isn't free. Let's be honest:

Per-call fork overhead
Spawning a process is ~tens of ms. For "compress this folder" or "hash this file," fine. For "verify 10,000 HMACs in a loop," brutal. You'd never build a high-throughput crypto service this way. I knew this going in—yyzTools hashes one file at a time, not a stream of requests. Low frequency is the prerequisite for this pattern.

Large-file hashing is slower
A static SHA256() call streams bytes in-process. The subprocess model means bytes cross the process boundary. For a 4GB ISO, you feel it. Acceptable for my use case; unacceptable for a backup service.

The stdout contract is the weak point
CLIs emit human-readable output, not machine-readable JSON. I hand-rolled a stable parser for each CLI's output. When a CLI upgrades and changes its output format, the parser can break. Easier to debug than a static ABI change (the CLI just fails loudly), but it's a maintenance surface.

I wish there were a standard "CLI emits JSON" convention. Some tools have it (gh, kubectl), many don't (openssl enc's output is a mess to parse). The inconsistency is the real friction.

Process lifecycle management
You own timeouts, zombie handling, cancellation. A static function call doesn't hang. A subprocess can. I had to build a work-queue with concurrency limits (don't spawn 200 magick.exe for 200 images) and cancellation. That's extra code you don't write for a static link.

Where I'd draw the line
This pattern fits when:

Low-frequency calls — desktop tools, not services
Fast upstream upgrades matter — security CVEs, new algorithms
You want transparent supply chain — auditable binaries
The CLI is mature and stable — FFmpeg, OpenSSL have decades of CLI stability
It fails when:

High throughput — a TLS server, a per-request crypto service
Large streaming I/O — backup, media transcoding at scale
The CLI output is unstable — you'd spend your life chasing format changes
I use the subprocess model for the 9 bundled CLIs in yyzTools. If I were building a media server or a crypto API gateway, I'd static-link (or use a proper service). The pattern is frequency-dependent.

A pattern worth naming
I haven't seen this called out as a named pattern, but it shows up: VS Code ships ripgrep and calls it. Many Electron apps bundle CLIs. The principle—"ship the stock CLI, spawn it, parse stdout"—is a middle ground between static linking and microservices.

Position on the dependency spectrum:

Static link Subprocess CLI gRPC service
Perf fastest (function call) medium (fork + IPC) slowest (network)
Upgrade cost recompile + regression drop a file redeploy service
Crash isolation none process boundary network boundary
Cross-language compile-time binding natural natural
Best for high-throughput core low-freq trusted capability cross-machine
The subprocess-CLI slot is underused. For a desktop app bundling many third-party capabilities, it's often the right slot.

The honest takeaway
If your tool calls a third-party engine a few times a session (not thousands of times a second), and you care about fast upgrades and transparent supply chain, shipping the stock CLI as a subprocess beats static-linking. You pay per-call latency and a parser to maintain; you gain zero-recompile upgrades and crash isolation.

Don't use it for hot paths. Do use it for "I need OpenSSL/FFmpeg/ImageMagick occasionally, and I don't want to recompile when they patch a CVE."

I'm building yyzTools — a free, local-first Windows productivity suite. Website: yyztools.com. The 9 bundled CLIs are OpenSSL, 7-Zip, FFmpeg, ImageMagick, pdfcpu, Aria2, RapidOCR, Everything, and Ghostscript.

Why I Built a Windows Desktop App with C++ + WebView2 Instead of Electron

yyzTools — Fri, 21 Aug 2026 08:40:17 +0000

I'm building yyzTools, a Windows productivity suite with 40+ tools fused into one install. This is the architecture decision I get asked about most.

The default path

When a developer today wants to build a desktop app, the default reflex is Electron. It's rational: HTML/CSS/JS, cross-platform, mature ecosystem (VS Code, Slack, Discord proved it works). If your team is frontend-heavy, it's almost a non-decision.

I didn't take that path. yyzTools is C++ (Win32) + WebView2 + Alpine.js + Vite. Windows-only. No bundled Chromium.

This post isn't "Electron is bad." It's "for a resident, lightweight, multi-feature desktop tool, Electron's costs outweigh its benefits, and here's what I picked instead."

Why Electron didn't fit this project

The key word is resident. yyzTools is a tool you install once and it sits in your tray, running every time you hit Alt+Space for the command palette, grab from clipboard history, fire OCR. It's not an app you open and close—it's always there.

Electron's model is "bundle a full Chromium per app." For an app you open occasionally, the ~200MB memory and multi-second startup is tolerable. For something that's always resident, it's a tax you pay every second the machine is on.

Nobody wants a clipboard manager + launcher eating 400MB of RAM just by being installed.

The alternative: WebView2 + a C++ host

Microsoft's WebView2 is a control that renders web content using the Edge engine already installed on Windows. No bundled browser. The runtime ships with Windows 11; on Windows 10 the installer guides the user.

So my stack:

C++ / Win32 host — owns the window, system calls, process management, all native work
WebView2 — renders the frontend pages using the system Edge
Alpine.js (~3KB) — frontend framework, no virtual DOM, no heavy build chain
Vite multi-entry — each feature page (command palette, OCR, translate, download...) is an independent bundle

The architecture is a four-layer sandwich:

Frontend pages (Alpine.js + vanilla JS)
        ↓  via web/lib/zen_api.js (unified wrapper)
WebView2 bridge layer
   BindSync  → synchronous return (most methods)
   BindAsync → async callback (OCR, app-info)
        ↓
C++ NativeApi layer (FileManager / ProcessManager / ...)
        ↓
Win32 system API

The frontend never calls window.Zen directly. It goes through a ZenAPI wrapper class that normalizes return values—the C++ side has two JSON paths (hand-rolled strings vs boost::property_tree) where the same error field can be number 0 or string "0". The wrapper does String(res.error) === '0' to paper over it. (That's documented debt, not a hidden clever trick.)

What this buys

Lower memory. No Chromium process resident. The main process is a thin C++ host plus the system Edge it borrows.
Faster startup. No spinning up a fresh Chromium instance.
Smaller disk. The web runtime is shared across the system, not bundled per-app.
Native when needed. File ops, process management, OCR engine calls, screen recording—all C++, no IPC to a JS-land bridge for hot paths.

What it costs

Let's be honest about the tradeoffs, because this isn't a free lunch:

Windows-only. WebView2 is Microsoft's. If you want Mac/Linux, you need Electron or a full Qt port. yyzTools targets Windows, so this is fine—but it's the biggest constraint.

A hand-written bridge. Electron gives you mature IPC for free. With WebView2 you hand-roll the JS↔C++ channel (a "method name → callable" registry, sync/async variants, thread marshaling for async callbacks back to the UI thread). It's not hard, but it's code you own and maintain.

No type system on the boundary. The error field type drift I mentioned isn't caught by TypeScript—it's a runtime contract between C++ and JS. I normalize at the wrapper, but every new native method is a chance to introduce a new type mismatch. A typed IPC (like tRPC over a real protocol) would be safer; I chose simplicity.

Alpine.js means no React ecosystem. Alpine is great for "many simple pages" (which a productivity suite is). But if I wanted a complex single-page app with a rich component library, I'd miss React's ecosystem. The pages here are intentionally simple—search box, settings panel, result grid—so Alpine fits.

You need C++ people. A pure-frontend team can't extend the native side. This is a real org constraint. If your team can't staff Win32 expertise, Electron is the pragmatic call, period.

When you'd make the same call

I'd pick this again specifically when all four are true:

The app is resident (tray, autostart, always-on) — the memory tax compounds
Windows is the target — WebView2 is Windows-only
You need native system access — file/process/clipboard/OCR, where C++ beats a JS bridge
You have C++ capacity — someone can own the host and bridge

If any of those is false, Electron (or Tauri) probably wins. yyzTools happened to clear all four, so the C++/WebView2 path was correct here. It would be wrong for a cross-platform app, or a resident app with no native API needs, or a team of pure-frontend devs.

The takeaway

"Electron vs native" isn't a moral question—it's a fit question. The reflexive "always Electron" is wrong for resident, native-heavy, Windows-targeted tools. The reflexive "never Electron" is wrong for cross-platform or frontend-heavy teams.

The useful question to ask when you start a desktop project: is this app resident, and does it need native system access? If yes to both and you're on Windows, the C++ + WebView2 path is worth the C++ staffing cost. If no, Electron's defaults will serve you faster.

yyzTools is the former. Your project might be the latter. Pick on fit, not on what's trendy.

I'm building yyzTools — a free, local-first Windows productivity suite. Website: yyztools.com. I write about the architecture decisions behind it.