At Gerus-lab, we build a lot of tools. Internal dashboards, CLI wrappers, lightweight desktop utilities for clients. And for the last few years, like almost everyone else, we defaulted to Electron or Tauri when someone asked for "a desktop app."
Last week, one of our engineers went down a rabbit hole after reading a trending post about Win32 API. The frustration was familiar: modern Notepad uses ~50 MB of RAM. The equivalent Win32 C application? 1.8 MB. That's not an edge case — that's a 27x difference for a text editor.
So we ran our own test. Here's what we found.
The Problem We Ignore Every Day
Electron ships Chromium. Always. Even if your app is a 300-line todo list, you're bundling a full browser engine. Tauri is better — it uses the system WebView — but you're still rendering HTML.
We've normalized this. 200 MB for a chat app? Fine. 150 MB for a note-taking tool? Whatever. We're in 2026, RAM is cheap.
But the accumulation is the problem. Open 10 Electron apps and you've committed 2 GB before you've done anything. On a server or embedded system, this isn't theoretical — it's a hard blocker.
At Gerus-lab, we work with clients who deploy tools on edge hardware, kiosk systems, and industrial machines. "Just add more RAM" isn't always an option.
What Win32 Actually Gives You
Win32 isn't a framework. It's a direct contract with the Windows kernel. The core model is message-based:
while (GetMessage(&msg, NULL, 0, 0) > 0) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
Your window procedure handles events: WM_CREATE, WM_PAINT, WM_SIZE, WM_DESTROY. That's it. No virtual DOM. No event delegation system. No hydration. Just messages and handlers.
The result: a Win32 app starts in milliseconds and sits at under 2 MB idle.
We Rewrote a Client Tool in Win32
One of our clients runs a logistics coordination tool — a small desktop utility that monitors a local TCP port and displays status updates in a floating overlay. The Electron version: ~180 MB at idle, 3-second startup, bundle size 85 MB.
We rewrote it in Win32 C over a weekend. The results:
| Metric | Electron | Win32 C |
|---|---|---|
| Idle RAM | ~180 MB | 3.2 MB |
| Startup time | ~2.8s | 0.12s |
| Bundle size | 85 MB | 480 KB |
| Install deps | Node + Chromium | None |
The Win32 version uses a layered window (WS_EX_LAYERED) with UpdateLayeredWindow for the overlay — which handles per-pixel alpha blending without a graphics framework. The entire thing is 800 lines of C.
Is it more complex to write? Yes. Is it worth it for the right use case? Absolutely.
The Part Everyone Forgets: Shaped Windows
One of the most interesting Win32 features that modern frameworks completely abstract away: you can make a window any shape you want.
Using SetWindowRgn with an HRGN object, you can define the window boundary as an ellipse, a bitmap silhouette, or any custom polygon. The OS handles hit-testing automatically — clicks outside the shape pass through to whatever's behind the window.
// Create an oval window
HRGN region = CreateEllipticRgn(0, 0, rc.right, rc.bottom);
SetWindowRgn(hwnd, region, TRUE);
// Since we removed the title bar, handle dragging manually
// In WM_LBUTTONDOWN:
SendMessage(hwnd, WM_NCLBUTTONDOWN, HTCAPTION, 0);
You can also drive the shape from a bitmap:
// Magenta = transparent, everything else = window surface
#define TRANSPARENT_COLOR RGB(255, 0, 255)
Scan the bitmap, build rectangular regions for each opaque row, combine them — and your window is shaped like the image. This is exactly how skins worked in WinAmp, Windows Media Player's old interface, and dozens of creative apps from the early 2000s.
For animation, you use layered windows with UpdateLayeredWindow which gives you per-pixel alpha, meaning your app can render animated sprites with smooth edges, proper transparency, directly on the desktop.
When Should You Actually Use This?
Honestly, Win32 is not the answer for most apps. If you're building a SaaS with a desktop client, a dev tool with a plugin ecosystem, or anything that needs to run on macOS and Linux — Electron or Tauri is the pragmatic choice.
But we've identified specific scenarios where Win32 is worth it:
1. Kiosk / embedded deployments — locked Windows machines where RAM is limited and startup time matters. Our client's logistics overlay is a perfect example.
2. Always-on system utilities — tray apps, monitoring agents, clipboard managers. These run 24/7. 180 MB vs 3 MB matters when it's always there.
3. High-frequency UI updates — if your app needs to repaint 60+ times per second (real-time telemetry, trading terminals, live dashboards), Win32 with direct GDI/GDI+ is significantly more efficient than a browser engine.
4. Minimal footprint installers — when your installer must be under 1 MB, or when you're deploying via enterprise MDM with strict size limits.
For everything else? Tauri is a reasonable middle ground. It uses the system WebView (no Chromium bundled), gives you Rust for the backend, and your bundle is typically 3-10 MB. Not Win32-lean, but nowhere near Electron.
What We're Actually Arguing Here
This isn't nostalgia for Win32. It's a reminder that the abstraction tax is real, and we rarely stop to calculate it.
We've built workflows around Electron because it's fast to ship and the ecosystem is great. But when a client asks why their tool crashes on a 4 GB RAM machine, the answer is often "because we shipped a browser with it."
At Gerus-lab, we specialize in building systems that work at the edges — embedded, constrained, high-throughput. Whether that's a Solana trading bot that can't afford latency, a TON blockchain integration running on minimal infra, or now apparently a Win32 overlay for a logistics dashboard.
The lesson: choose the right layer. Electron is a fantastic tool for the right problem. For the wrong problem, you're shipping a 200 MB anchor.
If you're working on a constrained-environment desktop tool and wondering whether a leaner approach is worth it — reach out to us. We've done this migration a few times now, and the performance wins are consistently larger than clients expect.
We're Gerus-lab — a software engineering studio specializing in Web3, AI systems, and high-performance backends. If you're building something that needs to be fast and lean, let's talk.
Top comments (0)