Microsoft's Abandoned FoxPro Rises Again: Runtime Rewritten in Rust, Compiled to WASM

A Language Sentenced to Death — Why Is Someone Bringing It Back?

Visual FoxPro stopped at version 9.0 and never received another update. Microsoft long ago announced end-of-life for this once-popular database development language. Yet a reality that the tech world tends to ignore persists: a large number of legacy business systems still run FoxPro-built applications in 32-bit mode to this day.

The reason isn't complicated — rewriting a business system that has been running for twenty years is often equivalent to bankrupting the business itself. For many small and medium-sized enterprises, that old application is the company's lifeblood. It reliably handles accounting, invoicing, and inventory management, and nobody dares to touch it. This is exactly the fertile ground from which this revival project grew: customers want to keep relying on their FoxPro applications and run them into the foreseeable future.

The project earned 277 upvotes and over 160 comments on Hacker News — a sign that it resonated with a community of developers equally trapped by the weight of legacy software.

Rebuilding an Old Language with a Modern Stack

The project's core philosophy is "same language, brand-new runtime." Rather than forcing old applications to adapt to a new language, the developer lets old code run untouched on a completely reimplemented runtime.

The technology choices are telling: the runtime is written in Rust and compiled to WebAssembly (WASM). This means a language once locked to 32-bit Windows theoretically gains the ability to run cross-platform — in a browser or sandboxed environment. Rust's memory safety and performance advantages also give this old language a more solid foundation than it ever had.

Even more critical is the approach to compatibility verification: the new runtime's behavior is validated against the real vfp9.exe (the original Visual FoxPro 9 executable). This "treat the original as the gold standard" methodology is the prerequisite for seamless migration of legacy applications — only behavioral parity gives customers the confidence to hand over their production systems.

WebAssembly (WASM) is a binary instruction format designed for a stack-based virtual machine, standardized by the W3C as a web standard — but its use cases have long since expanded beyond the browser. At its core, it's a portable compilation target: any language (C, C++, Rust, etc.) can be compiled into WASM bytecode and then executed in any environment that implements a WASM runtime, including browsers, server-side runtimes like Wasmtime/WasmEdge, and even embedded devices. For legacy system modernization, WASM's appeal lies in its sandbox isolation and cross-platform nature: code that once only ran on 32-bit Windows can break free from OS version and hardware architecture constraints once its runtime is compiled to WASM. The combination of Rust and WASM is particularly well-suited — Rust's toolchain has mature support for the wasm32 target, and Rust itself requires no garbage collector, producing WASM modules that are small, fast-starting, and free from the GC overhead that would otherwise pile on top of an already-complex legacy runtime memory model.

Fixing Historical Limitations, Then Adding Modern Capabilities

The revival isn't a simple clone — it also addresses several long-standing FoxPro pain points and adds features modern developers expect.

Breaking the 2GB Table Size Limit

The original FoxPro capped data tables at 2GB — a constraint that has become a real bottleneck in today's data-heavy world. The new runtime removes this limitation, allowing legacy applications to handle much larger datasets.

Supporting Legacy 32-bit .fll Plugins

Many FoxPro applications depend on third-party .fll extension libraries. The project implements the ability to continue loading legacy 32-bit .fll plugins — a critical capability for migration completeness, since enterprise systems often carry a pile of decades-old dependencies that can no longer be recompiled.

.fll files are Visual FoxPro's dynamic link extension library format (FoxPro Link Library) — essentially 32-bit Windows DLLs that follow specific export conventions. Developers use them to register custom functions in FoxPro, enabling native extensions for things like print controls, encryption algorithms, and hardware communication. The problem: these libraries were often compiled by third-party vendors twenty years ago, with source code long since lost and impossible to recompile for 64-bit or other platforms. Loading 32-bit .fll files within a WASM runtime is a significant technical challenge — it requires maintaining a compatibility layer outside the sandbox to handle 32-bit ABI calls, or leveraging translation mechanisms similar to Wine/FEX. The project's ability to achieve this represents a critical step in "compatibility completeness" and directly determines whether enterprise systems that heavily depend on third-party plugins are viable candidates for migration.

Introducing Lambdas, JSON, and HTTP Services

While preserving the old syntax, the author "threw in" lambda expressions, JSON support, and a built-in HTTP server. These additions give this ancient language the basic building blocks to connect with the modern web ecosystem — legacy business systems can now expose APIs and handle structured data.

What's Not Done Yet — and a Pragmatic Attitude

The project author is candid about the current state: report generation is not yet complete, and build artifacts are unsigned. For production environments, reports are often a core output of FoxPro applications, so this gap means it can't fully replace the original just yet.

On licensing, the project uses the MIT License — the author's reasoning is refreshingly direct: "Why not?" This open approach invites the entire community to participate in maintaining this "zombie language."

A Case Study in Legacy System Modernization

This project's value extends beyond FoxPro itself. It reflects a long-standing challenge in enterprise software that few are willing to tackle: how to extend the life of a legacy system without rewriting its core logic.

Rewriting is always the most tempting and most dangerous option. The approach of "preserving language semantics while replacing the underlying runtime" offers a lower-risk path. Using a modern foundation like Rust + WASM to carry a language from twenty years ago is both a technically romantic gesture and a pragmatically sound engineering compromise.

For teams still running businesses on legacy technologies like FoxPro, Delphi, or VB6, this project might offer some inspiration: old code doesn't have to die — the key is finding a modern foundation that lets it keep running.

"Preserve language semantics, replace the underlying runtime" is not a new idea invented by this project. There are several historical parallels: GraalVM's Truffle framework allows Ruby, Python, R, and other languages to run on the same JVM while sharing a JIT compiler; the .NET Mono project let C# applications run on Linux and macOS outside of Windows; and even earlier, Wine — which is not an emulator, but a reimplementation of the Windows API on Linux that allows Windows binaries to execute directly. The common challenge across all these projects is "consistency at the edges": mainstream code paths are relatively easy to reproduce, but real-world business systems often depend on undocumented corner-case behaviors and even bugs. This is precisely why the project uses vfp9.exe as its "gold standard" for behavioral testing — a specification document can never fully describe the true behavior of a commercial runtime that has been running for twenty years.