From Desktop C++ to the Browser: Rebuilding a Boardview Viewer as a Web App

Plenty of useful software is a desktop program that someone has to install. Moving it to the web removes that step, and it can also let you keep what the original got right. Here’s a recent example of ours: a boardview viewer, the kind of tool electronics repair people use to see a circuit board’s parts, pins and nets.

What we started from

OpenBoardView is a C++ desktop viewer under the MIT license. Its value is hard-won knowledge: file formats with no documentation, scrambling schemes, and rules of thumb for drawing parts when a file gives only pin positions.

We didn’t try to run the C++ in the browser. Compiling to WebAssembly would have brought its desktop interface along, and our site’s security policy keeps WebAssembly to the few pages that need it. We ported the readers to TypeScript instead, keeping their rules, and built a new interface on a canvas. KiCad and Eagle files we read from those formats’ public documentation.

Testing without the original

A port is only worth having if it reads files the same way. We had a rare gift for that: the open-source Glasgow board exists as a KiCad design and as two boardview exports made from it.

• The two boardview exports agree on every pin, within 1 mil. That 1 mil is the exporter rounding a mirrored coordinate.
• The KiCad design matches the export on 1,145 pins. The other four are bare mounting holes. Every matched pin is on the same net.
• On a real Eagle board, every signal pin lands on the end of a routed wire, mirrored parts included.

Then real files did what fixtures hadn’t. An open GenCAD board showed that flipped parts were drawn half a turn out, a rule we’d carried over from the original. A real MacBook board has one pin ten times beyond the board’s edge, which shrank the view to a speck until the outline took charge of it.

Not every format has had that test. Encrypted formats and some others have so far seen only files we made ourselves, and real ones may turn up surprises.

Files from strangers

A viewer opens whatever people drop on it, so every count and offset in a file is treated as untrusted. We ran thousands of cut and damaged copies through the readers: a reader may refuse a file, but it may not crash. A compressed file that tries to expand without limit gets stopped.

What the deployment taught us

Tests caught the logic. They didn’t catch this: on the live server the PDF worker wouldn’t start, because the web server sent .mjs files with a generic content type and the browser refused them. Every page still returned 200. We found it by driving the real site with a real browser after deploying. That’s the kind of thing a conversion turns up.

Is your program a candidate?

The full story is in the case study. If your business depends on a desktop program, the same approach may apply: keep the rules that took years to get right, replace what’s around them. See what a legacy app conversion involves.