FoxDev StudioFoxDev StudioDocumentationHow it is builtFoxScriptDownloadGitHubFor Visual FoxPro 9 applicationsYour FoxPro applications, at home on a modern machine.FoxDev Studio opens the projects, forms and tables you already have and runs them the way you remember: no rewrite, no conversion, no export step.DownloadGet startedHow it is builtCustomerCompanyWestern Trading Co.Credit limit25,000.00SaveIt picks up where you left offPoint it at a folder you have not opened in years, and what is there is what you get.Your project, as it isProjects, forms, class libraries, menus and reports open straight from the files you already have. Nothing is migrated first, and nothing is left behind.The designers you knowForms, classes, menus and reports are edited where you expect them to be, alongside the project manager, the Command Window and a debugger that stops on your line.Your data stays your dataTables, indexes, memos and databases are read and written in place. What sits on disk afterwards is the same kind of file it was before.Whatever it talked to, it still talks toThe system calls, the automation objects and the old add-in libraries your application leans on keep working, so the parts nobody wants to touch stay untouched.What it looks likeThe IDE, on Visual FoxPro's own sample projects. Every picture is a real session.Visual FoxPro's own Solution sample, imported and running: its launcher form on the Screen tab, the project's 123 forms, 7 menus and 11 class libraries in the explorer, and the runtime waiting for events.The editor lints through the runtime's own compiler, so what it underlines is what would fail.Stopped one step past a breakpoint in the Solution sample's main program: call stack, locals, watches, and the line it is on.A database container in the table browser: 8 fields, 17 records, memos a click away.FoxScript: lambdas answering HTTP routes, a 32-bit library called from inside one, listening on 8080.Built to match, not to approximateSmall differences are what break an old application: a number printed a column too wide, an event arriving a moment late, an error with the wrong number on it. So behaviour here is settled by asking Visual FoxPro itself and matching its answer, rather than by reading a reference page and hoping.What comes out of that is a runtime written from scratch: quick to start, self-contained, and straightforward about the corners it has not reached yet.1,722elements of the Visual FoxPro 9 language reference known to the runtime1,534of them exercised by a test that compares the answer with the product's3names it has not met yet; everything else runs, is ignored on purpose, or is refused by nameWhat Visual FoxPro 10 would have beenVisual FoxPro stopped at version 9, and at 32 bits. This is the same language, rebuilt on a foundation that has not been frozen since 2007. Four pieces are what make that possible.Where a call goes/and where the 32-bit world stops64-BIT32-BITThe form on screenReact, drawing straight from the tree belowrepaints one control, not the formThe live object treeevery control, with its properties and its eventsTHISFORM.lblGreeting.Caption = cMsgThe virtual machineyour code, compiled to bytecode, run in WebAssemblyyields a request, never blocksThe hostfiles, tables, COM, and 64-bit libraries in processSET LIBRARY TOfllhost.exea 32-bit process, holding your .fll64-bit, end to endThe ceiling that came with 32 bits is goneVisual FoxPro is a 32-bit program, and that decides more than it appears to. It is why a table stops at two gigabytes, why a memo file stops at two gigabytes, and why a big report runs out of memory on a machine with plenty to spare. The limits are signed 32-bit numbers buried in the file handling, not a licensing decision anybody made.FoxDev Studio is 64-bit throughout. Every file offset is 64-bit and a table is never read into memory at all, so the same .dbf that used to stop dead carries on into the hundreds of gigabytes. One thing to know before you lean on it: a table grown past two gigabytes will not open in Visual FoxPro again. If you still work in both, that is a one-way door.The offset/and what it reachesVisual FoxPro2,147,483,647bytes: the table stops at 2 GBthe leading bit carries the sign, which is why it is 2 GB and not 4FoxDev Studio9,223,372,036,854,775,807bytes: the offset is never what stopsevery byte of every read and write is addressed this wayWhat that buys one tableEvery square below is 2 GB: the whole of what a Visual FoxPro table could hold.2 GB279 squares: one FoxDev table of 130-byte records, 558 GB.At 1 KB records it reaches 4.4 TB, which is 2,200 of them.what stops it now is the DBF header's own record countThe virtual machineA compiler, and a machine built to run what it makesVisual FoxPro compiled your program to p-code and shipped a runtime to execute it. This is the same arrangement, made again: a compiler and a bytecode interpreter written in Rust and compiled to WebAssembly, so one machine runs your code wherever the application runs. The editor checks what you type through that very compiler, so what it underlines and what the runtime refuses cannot drift apart.A running program is a fiber. When it needs something from the world outside (a message box, a modal form, the next record) it does not call out and block; it yields, the work is done while the machine is off the stack, and the answer is handed back. That is why MESSAGEBOX() stops your program without freezing the window behind it, why READ EVENTS waits without spinning, and whySetFocus can fire GotFocus, and Init can run while a form is still being built, in the order FoxPro always did it.How the machine works and what it runs.The screenThe form you see is the object tree, not a picture of itA running form is a live tree of objects with the properties you would expect, and the interface is drawn straight from that tree by React. Each object watches only itself, so THISFORM.lblGreeting.Caption = cMsg repaints one label rather than the whole form. On a dense screen that is the difference between instant and sluggish.The same tree is what the designer edits, one step earlier. There is no second model kept in step with the first, which is the usual place a form and its designer start telling different stories.The 32-bit bridgeYour old libraries still load, though nothing here is 32-bitAn .fll is a 32-bit image, and every process in a 64-bit application is 64-bit, so nothing inside the application itself could ever open one. Rather than tell you it is impossible, SET LIBRARY TO starts a small 32-bit process whose only job is to hold your library, and the runtime talks to it. The calls are synchronous, because a program may call into a library halfway through an expression, and an answer that arrived later would not be an answer. It is measured against real libraries: the encryption library, FoxTools, and libraries built from Microsoft's own API samples.Nothing 64-bit needs the bridge: DECLARE ... DLL reaches a modern library in the same process, and automation objects are reached the way they always were. The old road stays open; it just is not the only one any more.FoxScript: the same language, with more roomEverything you have written still means what it always meant. FoxScript only adds on top: a block you can hand to something else to run later, and a way to answer a web request from the code that already knows your business.server.prg/FoxScript&& your old add-in libraries load just as before
SET LIBRARY TO "vfpencryption71.fll" ADDITIVE

LOCAL oServer
oServer = FoxScript.Http.CreateServer()

oServer.Get("/api/v1/customers/:id", LAMBDA(req, res)
LOCAL lnId
lnId = VAL(req.Params("id"))

SELECT * FROM customer WHERE cust_id = lnId INTO CURSOR c_cust

IF RECCOUNT("c_cust") > 0
res.Status(200).Json(FoxScript.Data.CursorToJson("c_cust"))
ELSE
res.Status(404).Json('{"error": "Not found"}')
ENDIF

USE IN c_cust
ENDLAMBDA)

oServer.Listen(8080)
READ EVENTS
Every line of that runs on the same runtime your forms do. The queries, the cursor and the library call are ordinary FoxPro; the lambda and the server are what FoxScript adds: no second language, no service to stand up beside it.The keywords and the HTTP APIare each written down in full.DownloadThe nightly is rebuilt from every push to main and published as a pre-release on GitHub. Unsigned, so the first launch asks you to confirm.WindowsThe installer (.exe) and the runtime (.zip), x64.Ubuntu and other LinuxAn AppImage and a .deb, x64.Source, on GitHubFoxDevCommunity/FoxDevStudio: the IDE, the VM, this site, and every release.Read the documentationEach part of the product is written down, including the parts that are not there yet.OverviewWhat FoxDev Studio is, and where each part of it is described.Getting startedInstall the IDE, open a project, run a form, ship an executable.Required toolingWhat you need to run the IDE, and what you need to build it from source.The virtual machineFibers, host requests, and why the VM never blocks.BytecodeThe module format, how a program compiles, and what a frame holds.Instruction referenceEvery instruction with its operands and stack effect, generated from the VM source.The new keywordsLAMBDA, ENDLAMBDA, the FoxScript namespace and two new value types.The HTTP APIFoxScript.Http, the Node side of it, and why it is shaped this way.What is comingWork already mapped out, roughly in the order it is being built.The last of the languageA short list of corners is still open, each one checked against the original as it closes.ReportsThe report designer and the report engine, band by band, measured the same way the rest was.Tables past two gigabytes, as a format of their ownThe 64-bit offsets are there today; a container that is honest about the DBF header's limits comes next.An installer for what you shipYour application handed to the people who use it as a single thing they can run, with nothing to set up first.FoxDev Studio is an independent project, and one still growing. Thedocumentation says where it is and where it goes next.Visual FoxPro is a registered trademark of Microsoft Corporation, used here only to name the language being implemented.

FoxDev Studio is presented as a framework designed to manage existing Visual FoxPro projects, forms, and tables directly on modern machines without requiring migration, conversion, or export steps. The system ensures that users can interact with their existing projects, including forms, classes, menus, and reports, within the familiar environment, while maintaining the integrity of the data and the application's underlying system calls and add-in libraries. The core feature involves opening the project directly from existing files, meaning nothing is migrated first, and nothing is left behind, allowing designers to edit forms and classes alongside the project manager and debugger. Furthermore, the architecture ensures that data structures like tables, indexes, memos, and databases remain in place, and the persistence of files is unaltered, ensuring that whatever the application talked to continues to do so.

The technical foundation of the system addresses the constraints of legacy systems through a sophisticated approach to bit architecture. Visual FoxPro operates as a 32-bit program, which dictates operational limits, such as the two gigabyte restriction for tables and memo files, a limitation rooted in signed 32-bit numbers embedded in file handling rather than a deliberate licensing decision. In contrast, FoxDev Studio operates entirely in 64-bit, allowing for expansive addressing. This distinction is critical because the studio handles file offsets in 64-bit, ensuring that data containers, such as a table, can logically extend far beyond the 2 gigabyte limit imposed by the older system, enabling capacities up to hundreds of gigabytes for large datasets.

The execution environment relies on a virtual machine that employs a fiber-based model to manage operations. This design allows running programs to yield control when waiting for external events, such as a message box or the next database record, preventing freezing. This non-blocking execution model is facilitated by the virtual machine, which is compiled from the code into bytecode, executed via a Rust-based engine compiled to WebAssembly, providing a unified runtime wherever the application runs. Furthermore, the compiler functions as a runtime, checking the code during the editing process to identify potential failures, which informs the editor about what would fail.

The user interface is based on a live object tree, where forms are not static pictures but dynamic representations of an object hierarchy. This structure is managed by a system akin to React, where objects watch only themselves, allowing for highly efficient repainting of only the necessary controls, which improves performance on dense screens. This object tree serves as the source for design editing, providing a single, coherent model for the application.

The language evolution incorporates FoxScript, which extends the existing capabilities by introducing concepts like lambdas and an HTTP API, allowing code to handle web requests. This addition does not introduce a second language but provides a means for code to interact with external services. For instance, FoxScript enables methods like creating a server to handle HTTP requests, where lambda functions define the logic for processing parameters and returning responses, integrating directly with underlying data operations like cursor manipulation.

The system manages legacy compatibility through a bridge mechanism. While the FoxDev Studio is 64-bit, it interacts with 32-bit components like .fll files residing in a separate 32-bit process. This process acts as a host, allowing the 64-bit runtime to communicate synchronously with the 32-bit library, ensuring that older library calls function as they did previously while operating within the modern, larger address space. This approach allows automation objects and other system calls to operate as they always have, maintaining the continuity of established application behaviors.

The delivery of the product emphasizes a holistic package. The system offers installers for both Windows and Linux environments, packaged as executable installers and runtime zip files. The documentation emphasizes that the project is an ongoing, evolving entity, with nightly builds published on GitHub, reflecting the continuous development and refinement of the system, which includes addressing future limitations such as tables exceeding two gigabytes and refining the report engine.