FoxDev Studio's FoxPro Revival Inherits a 20-Year-Old Flaw

FoxDev Studio, a GitHub project promising to run Visual FoxPro 9 applications as native 64-bit software, was five hours old when a Hacker News commenter who says they worked on Microsoft's Fox team said its file format still lets anyone rewrite a stored procedure with nothing more than a text editor.

The GitHub repository was created by the organization FoxDevCommunity at 7:10 p.m. UTC on Sept. 22, according to GitHub's own record of it. Its creator, posting under the Hacker News handle boredjohnny, submitted the project to Hacker News at 9 p.m. that evening under the title "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived." By the time this was reported, close to four hours later, the post had reached 160 points and the repository had drawn 17 stars, one fork and an MIT license.

What FoxDev Studio claims to run

FoxDev Studio's own site describes an IDE and runtime, built on Electron, React and "a Rust virtual machine in WebAssembly," that opens existing Visual FoxPro projects, forms and tables "the way you remember: no rewrite, no conversion, no export step." Visual FoxPro is a 32-bit language and database system Microsoft discontinued in 2007, nine years after buying Fox Software. The site's own figures put its coverage at 1,722 elements of the Visual FoxPro 9 language reference, with 1,534 of them checked against the original product's own answers and three not yet implemented. Because it addresses memory as 64-bit throughout rather than Visual FoxPro's signed 32-bit offsets, the site says a table can grow past the original two-gigabyte ceiling into the hundreds of gigabytes, though a table grown that large will no longer open in Visual FoxPro itself.

The database flaw nobody has patched

Visual FoxPro applications keep their business logic in a Database Container, or DBC, a file that stores stored procedures as plain text inside a memo field with no permissions system of its own. A commenter using the handle mikestew wrote in the same thread that they filed a bug on that design more than 20 years ago while working on Microsoft's Fox team, and that it was never going to be fixed "without rewriting large parts of how the DB engine works." Because a DBC must stay writable to every user for the format to function, mikestew wrote, "with a little technical knowledge, one can modify that INSERT trigger to whatever you like," using a text editor and bypassing whatever checks the FoxPro runtime performs.

boredjohnny replied in the same thread that "FoxDev reads the DBC the same way VFP does, so today it inherits the hole exactly," and proposed hashing the stored-procedure text into the compiled executable so the runtime could refuse to run a container whose procedures do not match. That fix does not exist yet; it is an item added to a list after mikestew's comment, not a shipped patch.

Built in hours, and it shows

boredjohnny confirmed in the thread that the runtime was "LLM assisted like most stuff nowadays," built for a client described only as one of their father's friends, who runs a shop and wanted bigger tables than Visual FoxPro's two-gigabyte limit allows. Several commenters said the project's own website reads as AI-generated, citing lines like "The editor checks what you type through that very compiler, so what it underlines and what the runtime refuses cannot drift apart." One asked outright whether the project had been vibe-coded, noting it had one commit and no visible history when the thread began.

boredjohnny's own replies did not settle the question. Hacker News moderator dang told boredjohnny directly: "Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here... The project itself is fine, of course, to submit to HN. We just want text on this site to be entirely human-written." The comment dang was responding to was a lengthy technical explanation of the project's WebAssembly boundary design, posted 12 minutes after boredjohnny's own admission that the runtime itself was LLM assisted.

Time (UTC)	Event
7:10 p.m., Sept. 22	FoxDevCommunity creates the FoxDevStudio repository
9:00 p.m.	boredjohnny submits it to Hacker News
10:49 p.m.	mikestew posts the DBC security warning
12:10 a.m., Sept. 23	Moderator dang tells boredjohnny to stop posting AI-generated comments

What would make this trustworthy

None of this proves FoxDev Studio's runtime is broken. Its own figures on language coverage go further than most week-old side projects manage, and a 64-bit file format is a real answer to a real limit. What it does mean is that nobody outside the repository has independently checked whether those 1,534 tested language elements behave correctly under real workloads, whether the WebAssembly sandbox holds up against a hostile FoxPro program, or how the proposed hash-based fix for the DBC hole will work once it is written. FoxDevCommunity has not published a security policy, a roadmap, or the identity of anyone besides boredjohnny behind the project. A five-hour-old repository with 17 stars asking businesses to point it at production Visual FoxPro data is a different claim than an established one: the same gap OpenStock's 17,700 GitHub stars ran into when its data-source gaps turned out to matter more than its star count, or that the DeepSeek coding harness's 233,000 stars earned with years of commits behind it rather than a single push to main. Whether FoxDev Studio earns that kind of record depends on commits nobody has written yet.