The runtime · Legacy systems
Bring dead software back to life.
The 30-year-old binary that still runs the business — reconstructed, run natively, and kept operational as everything around it changes.
Somewhere in most companies is a program nobody understands anymore — no source, no docs, no one left who wrote it — that the business still depends on. Perslis can take that binary, reconstruct how it works, and run it natively on a modern Mac without a VM or Wine. Desktop binaries (DOS, Win16, Win32) run directly on an in-house runtime. Larger server and mainframe systems are connected through their interfaces — APIs, terminals, data contracts — rather than emulated. In both cases the pattern is the same: understand it first, then operate it, then keep it operational.
The problem: software older than the people running it
Legacy software doesn't fail because it's bad — it fails because it's opaque. It works, but nobody knows how, so nobody dares touch it, so it slowly becomes a landmine the whole business tiptoes around. The usual "solutions" are a full rewrite (expensive, risky, often abandoned) or a virtual machine museum-piece (fragile, and it doesn't make the thing any more understood). Perslis takes a different path: reconstruct the understanding that was lost, then operate from that.
What “reconstructing a dead system” means
A 32-bit Windows program is a PE32 file — a Portable Executable that packs its machine code, its imported Windows APIs, and its memory layout in a format Windows understands and macOS does not. Perslis's runtime works through it directly:
- Parse the PE32 headers to find the code, data, and import sections.
- Rebuild the import tree and call-graph — which Windows APIs the program calls, and how its own routines connect.
- Resolve each imported API to its own implementation of that call.
- Reconstruct the environment the program expects and map its code into virtual memory.
- Interpret the x86 instructions directly on your Mac.
It reads a dead binary and brings it back — no source, no docs, no Windows, and no emulator translating in the background.
Understand
Import tree, call-graph, dependencies — the architecture of software nobody documented.
Rebuild
Detect and provision the runtime it expects — DOS, Win32, or a heavier engine — automatically.
Run
The binary executes natively on macOS. No VM in the background, no window to babysit.
Keep alive
Wrap it into a native app, monitor it, maintain it as the systems around it change.
Figure 1 — Reconstruction, not emulation. Understanding comes first; native execution follows from it.
An honest boundary
"Run any legacy system" would be a blank check, and we won't write it. Here's the real shape of what Perslis does:
- Desktop binaries (DOS, Win16, Win32): strong native support. This is the core case, and it runs directly.
- Server & mainframe (COBOL, AS/400): Perslis maps and connects through the interfaces — APIs, terminal emulation, data bridges. It orchestrates them; it is not a mainframe emulator.
- Legacy web apps (classic ASP, old PHP): the codebase and dependencies get mapped and understood; running them depends on whether a runtime still exists.
- Embedded / firmware: Perslis can read and analyze the code, but executing it needs the target hardware or an emulator.
The map is always achievable. Native execution is achievable for the desktop tier. That distinction is the honest version of the promise — and it's still a capability almost nothing else has.
Why this belongs in an operational runtime
Reconstructing a binary isn't a party trick — it's the same muscle Perslis uses everywhere: understand a system you didn't build, before you touch it. Legacy software is just the extreme case, where the understanding was lost entirely. If the runtime can bring back a dead .exe, the modern systems on your desk are well within reach.