Jake Savin

Previous: A new Frontier: The Real Start

The early phase isn’t dramatic, but it’s important.

Before Frontier could become useful again, it had to be buildable on modern operating systems, readable, writable, browsable… survivable. This is where the rubber hit the road.

One could easily imagine that the hard part about a project like this is preserving the existing code, but the hard part is actually preserving the meaning of the existing code after the world it was written for has mostly disappeared. (And being willing to delete things!)

When I started in October, the work wasn’t about adding features. It was about setting up the minimum conditions required to worked honestly in this code bringing in the context of modern software development and operating systems: 64-bit, ARM and Intel support, POSIX compliance, ANSI C, modern file handling, dependency minimization, and a database path that didn’t immediately collapse into a pile of mush the second it touched current hardware.

The core idea was to make it very portable (Linux, MacOS, Windows), very opinionated about sticking to standards (ANSI-C, POSIX, minimal and encapsulated OS-specific API dependencies), and to strip away all of the cruft from the 1990’s and early 2000’s that had been holding Frontier back and making it difficult to reason about. That also meant it needed to start as a headless app, with a CLI interface, and later a REPL. That was the only way to viably push into the modern era.

Some of the early work was obvious: clearing out dead build scaffolding, old project files, old toolchain baggage, and old assumptions that had survived long past their expiration date. Necessary, but not fun and not particularly interesting.

Then it got real: A headless Frontier that can’t load Frontier.root isn’t a viable platform since so much of what Frontier is, is implemented in UserTalk in Frontier.root. I quickly turned to a series of pushes on this front: serializer round-trips, byte order normalization, legacy header decoding, migration behavior, root hydration, migrating rich-text to RTF instead of 3rd-party legacy formats, and all the stuff that would have made most people run fast in the other direction. If I didn’t have AI assistance this stage of the work would have been at least grueling, and for me personally probably impossible to do successfully.

This is also where it stopped being theoretical for me. Once I was in the database path, understanding how the ODB actually worked, and learning where the problems and assumptions were, we went from “let’s see if it compiles” to “Can this code survive in the present tense?”

A lot of the early wins were small, concrete, and frankly boring: Decode old database headers correctly, convert legacy Pascal-format table payloads to modern ones, stop clobbering the original root files during migrations, add DB scanners so I can see what’s actually there, and build a file access layer that didn’t depend on MacOS or Windows assumptions.

It turned out that this wasn’t side work before the “real” project. This was the project: The overarching goal was to ensure that Frontier’s old databases could be read, migrated, written back out, and trusted on modern systems. That would open it up and make it possible to work with Frontier again as a real runtime in a terminal context: REPL, debugger, scripting improvements, AI-assisted workflows…

Leveraging Claude Code I created a substrate for all the future work: Canonical modern database, headless runtime that works with legacy system data and code, planning docs and instrumentation to keep me and the AI honest, and enough structure and “memory” that I didn’t have to reinvent the wheel every time I wanted to work on the next piece.

It’s not glamorous but this time spent early on was essential for enabling the subsequent AI-assisted work. The critical pieces were first making sure the code could compile and run well enough to shift into a stepwise process for moving things forward against a documented plan. In parallel I developed methodologies for documenting work and next steps: test-driven-development (TDD), architectural docs and decision logs, capturing and codifying important prior art, and a set of Claude Code skills and agents with specific expertise that would accelerate the work and reduce mistakes.

More soon…