FoxDev Studio is a development environment that runs Visual FoxPro applications as they are, without requiring migration, conversion, or a rewrite. It opens existing projects, forms, class libraries, menus, and reports directly from the files already on disk. Nothing is transformed first, and nothing is left behind. For organizations still running applications built on a language that Microsoft stopped updating in 2007, the tool offers a path forward that does not require rebuilding from scratch.

The problem it addresses

Visual FoxPro reached its final version at nine, and it stopped at 32-bit architecture. Those 32-bit constraints shaped the applications built on the platform in ways that went beyond licensing decisions. Tables were capped at two gigabytes because file offsets were signed 32-bit integers buried in the file handling layer. Memo files hit the same wall. A large report could exhaust the memory available on a machine with plenty of free resources to spare. These were not design choices anyone made deliberately; they were the mathematical limits of a 32-bit address space.

For years, teams running Visual FoxPro applications faced a narrow set of options: continue maintaining aging software on constrained infrastructure, or undertake a costly and risky rewrite in a different platform. Neither option was appealing, and many organizations chose to do nothing, letting their applications age alongside the infrastructure they ran on.

What FoxDev Studio does differently

FoxDev Studio is built as a 64-bit runtime throughout. Every file offset is 64-bit, and tables are never fully read into memory, which means the same .dbf file that previously stopped at two gigabytes can now carry data into the hundreds of gigabytes. The runtime is written from scratch and compiled to WebAssembly using Rust, which means the compiler that checks what a developer types and the interpreter that runs the compiled code are the same tool. What the editor underlines, the runtime enforces, and the two cannot drift apart.

The environment opens projects the way Visual FoxPro always did. The project manager, Command Window, and debugger are all present. Forms are edited alongside the class libraries and menus they depend on. Tables, indexes, memos, and databases are read and written in place, so what sits on disk afterward is the same kind of file it was before. Old add-in libraries, system calls, and automation objects continue to work. The parts of an application that nobody wants to touch remain untouched.

How the runtime handles concurrency and the interface

A running program in FoxDev Studio operates as a fiber rather than through blocking calls. When the program needs something from the outside world, such as a message box, a modal form, or the next record, it yields instead of calling out and freezing. The work continues while the fiber is off the stack, and the result is handed back when it arrives. This is why a message box stops the program without freezing the window behind it, and why READ EVENTS waits without spinning.

The interface layer is drawn directly from a live tree of objects rendered by React. Each object watches only itself, so changing a label's caption repaints that one label rather than redrawing the entire form. The designer edits the same object tree, one step before runtime, which means the form and its visual representation cannot tell different stories from each other.

Handling legacy libraries and adding new capabilities

Visual FoxPro's .FLL libraries are 32-bit images, and every process in a 64-bit application is 64-bit, so nothing inside the application could open one directly. Rather than reject those libraries as incompatible, FoxDev Studio starts a small 32-bit process whose sole job is to hold the library, and the runtime communicates with it synchronously. This matters because a program might call into a library partway through an expression, and an answer arriving later would not be valid. The approach has been tested against real libraries including encryption libraries, FoxTools, and libraries built from Microsoft's own API samples.

For code that does not need the 32-bit bridge, modern libraries are reachable through the standard DECLARE DLL mechanism, and automation objects work as they always did. FoxScript, the scripting layer built on top of the runtime, adds HTTP server capabilities without introducing a second language. A developer can attach a handler to a web request using the same FoxPro syntax already embedded in the application's business logic.

The state of the project

The product is built from every push to the main branch and published as a pre-release on GitHub. The nightly build is unsigned, so the first launch prompts the user to confirm. The documentation covers every part of the product, including the parts that have not yet been built, and the work is mapped out roughly in the order it is being constructed.

For developers maintaining Visual FoxPro applications, FoxDev Studio represents something that did not exist before: a way to extend the life of existing code on modern infrastructure without rewriting it, converting it, or losing access to the files and libraries the application already depends on.