FoxPro Stopped at Version 9 in 2007. Someone Moved It to a New Runtime
A customer wanted to keep a Visual FoxPro app in production, so foxscript puts the same language on a Rust/Wasm runtime, keeps old .fll add-ins loading, and lifts the 2 GB table ceiling. Reports aren't done and builds are unsigned.
Visual FoxPro’s last release was version 9, in 2007. What happened next is easy to guess: plenty of the code didn’t stop. It is still running, as 32-bit Windows binaries, in shops where nobody wants to be the person who touches it, holding business rules that were never written down anywhere else.
The reason is not sentimental. Replacing a twenty-year-old line-of-business application usually costs more than the application is worth, and the delivery date is not something anyone can promise. Rewriting a system that already works is a well-known way to lose the customer. So maintenance continues by default, until the person who knows the code retires.
A customer pushed this into existence
foxscript is what came out of that. According to the project, a customer wanted their application to keep producing for the foreseeable future, so here it is: the same language on a new runtime.
The runtime is written in Rust and compiled to WebAssembly. The detail worth pausing on is “checked against the real vfp9.exe.” Compatibility is validated against the original interpreter rather than reimplemented from a specification that never really existed. It is a slower way to work, and a more credible one for a language with no formal standard. Choosing wasm also leaves room to run somewhere other than a 32-bit Windows process, though the available material does not describe a migration path.
What carried over, and what was added
The compatibility item that matters most is that old .fll add-ins still load. .fll files are FoxPro’s 32-bit extension libraries, and in many installations the critical logic lives inside one, with the source code long gone. Whether an old application still works often depends on whether those binaries load at all, not on whether the syntax is supported.
On the additions: tables are no longer capped at 2 GB, the older ceiling set by the DBF format and 32-bit addressing, which a growing log table or a full scan will eventually reach. Lambdas, JSON, and an HTTP server are in as well. JSON covers integration with outside systems, and the HTTP server lets a legacy application expose an interface directly instead of sitting behind another layer. None of this is language design progress; it is clearing a few obstacles between a 1990s codebase and current infrastructure.
Where it stands
Reports aren’t done. For a large share of FoxPro deployments, reports are the business itself — invoices, statements, month-end printouts — and without them the system cannot be replaced in production at any real scale.
The builds are unsigned, so Windows will warn about them and enterprise distribution has to handle signing on its own. The license is MIT.
Those gaps don’t make the project unserious. The goal isn’t to reinvent FoxPro; it’s to keep the part that is already written running. The Hacker News thread drew 288 points and 170 comments, which suggests the topic lands with more than FoxPro users — anyone maintaining a system that can’t be shut down and can’t be rewritten at a price anyone will pay.