Old Source Code Is Useful. Copying It Isn't the Point.

Mike·September 6, 2026·Work documented: February 4, 2026·20 views

Having thirty-year-old source code available doesn't mean the job is to transcribe it. Here's how I actually use historical material as research instead of a shortcut.

I said in the last entry I'd come back to this, because it's the kind of thing that's easy to say correctly in one sentence and then get wrong in practice if you're not paying attention. So: having the Video Toaster's source available doesn't mean the job is "go copy the good parts into a modern language." That's not research, that's just slow transcription with extra steps, and it would also potentially be a licensing mess I have no interest in stepping into.

What I'm actually doing with it

When I read old source — Toaster code, DigiPaint's painting engine, whatever else turns up as this project goes on — I'm reading it for behavior and architecture, not for lines to lift. What data structure did they reach for when they needed to composite video in real time on hardware with no headroom to spare? What order did they do operations in, and why that order and not another one? Where did they put the boundary between "the hardware does this" and "software does this," and does that boundary still make sense on completely different hardware forty years later?

Those are architectural questions. The answers to those questions are useful to me. The literal C (or 68k assembly, in some of the older stuff) that implements those answers on a machine that hasn't been manufactured in decades is a lot less useful, because it's solving problems — memory pressure, clock speed, a specific bus architecture — that mostly don't exist on the hardware I'm targeting anymore. Studying WHY something worked survives the trip to modern hardware. WHAT LINE OF CODE did it survives a lot less well.

Provenance matters, and clean-room separation isn't paranoia

I try to keep a clean separation between "I read this and now I understand the problem better" and "I am now writing code." That's not me being precious about it — it's just good practice any time you're working with someone else's historical material, licensed release or not. If I understand a design decision well enough to reimplement it from a description of the problem, without the original code open in another window while I type, that's a real, defensible clean-room boundary. If I'm translating line by line, that's not research anymore, that's a port, and it comes with a completely different set of obligations I'm not trying to take on here.

This matters doubly because NewTek's release explicitly comes with usage terms, and even generous ones deserve to be respected on their own terms rather than stretched to cover something the release wasn't meant for.

A concrete example: DigiPaint

DigiPaint's painting engine had to do real-time brush rendering and color manipulation on hardware that measured its memory in kilobytes it could actually spare for the framebuffer. Reading how they approached that taught me something about where the actual hard constraints in a painting tool live — it's rarely the brush math itself, it's how aggressively you can avoid touching memory you don't have to touch. That's a genuinely portable lesson. It shows up again in completely different form when I get to display architecture a few entries from now, and — spoiler for an entry I haven't written yet — getting that lesson wrong is a real part of why an early display approach didn't survive contact with actual requirements.

So: old source code, useful. Old source code as a find-and-replace target for a modern rewrite, not useful, and honestly a little bit of a trap. Next up, the project this research actually turned into: Project Nu-Day.