- Published on
Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived
- Authors
- Name
- DeepHorus
Microsoft retired Visual FoxPro in 2007, but a revival has arrived anyway: FoxDev Studio, a rebuild that opens the projects, forms and tables developers already have and runs them the way they remember. There is no rewrite, no conversion and no export step β point it at a folder untouched for years and what is there is what you get. Projects, class libraries, menus and reports open straight from existing files, with nothing migrated first and nothing left behind. Tables, indexes, memos and databases are read and written in place, so what sits on disk afterwards is the same kind of file it was before.
Visual FoxPro stopped at version 9 and at 32 bits, a ceiling that shaped far more than it appears. The two-gigabyte caps on tables and memo files, and reports running out of memory on machines with plenty to spare, trace to signed 32-bit numbers buried in file handling rather than any licensing decision. FoxDev Studio is 64-bit throughout: every file offset is 64-bit and a table is never read into memory at all. The same .dbf that used to stop dead now carries on into the hundreds of gigabytes. Users should note one caveat β a table grown past two gigabytes will not open in Visual FoxPro again, making that a one-way door.
Compatibility is settled empirically rather than by reading a reference page: behaviour is decided by asking Visual FoxPro itself and matching its answer, since a number printed a column too wide or an error with the wrong number can break an old application. What emerges is a runtime written from scratch β quick to start, self-contained, and straightforward about the corners it has not reached yet. System calls, automation objects and the old add-in libraries an application leans on keep working, so the parts nobody wants to touch stay untouched.
As before, FoxDev Studio compiles programs to p-code and ships a runtime to execute it, but the compiler and bytecode interpreter are written in Rust and compiled to WebAssembly. One machine therefore runs the code wherever the application runs, and the editor checks what you type through that same compiler, so what it underlines and what the runtime refuses cannot drift apart. Running programs execute as fibers that yield instead of blocking, which is why MESSAGEBOX() stops a program without freezing the window behind it. READ EVENTS waits without spinning, and SetFocus, GotFocus and Init fire in the order FoxPro always did.
A running form is a live tree of objects drawn straight by React, and each object watches only itself. That means THISFORM.lblGreeting.Caption = cMsg repaints one label rather than the whole screen β on a dense form, the difference between instant and sluggish. The designer edits that same tree one step earlier, with no second model kept in step, which is where a form and its designer usually start telling different stories.
Legacy .fll libraries pose a harder problem, since a 32-bit image cannot load inside a 64-bit process. SET LIBRARY TO instead launches a small 32-bit process whose only job is to hold the library, with synchronous calls between the two. Together, these four pieces place a modern foundation under a language frozen for nearly two decades.
