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.
Point it at a folder you have not opened in years, and what is there is what you get.
Projects, forms, class libraries, menus and reports open straight from the files you already have. Nothing is migrated first, and nothing is left behind.
Forms, 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.
Tables, indexes, memos and databases are read and written in place. What sits on disk afterwards is the same kind of file it was before.
The 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.
The IDE, on Visual FoxPro's own sample projects. Every picture is a real session.
Small 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.
Visual 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.
64-bit, end to end
The ceiling that came with 32 bits is gone
Visual 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.
The virtual machine
A compiler, and a machine built to run what it makes
The screen
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 bridge
Your old libraries still load, though nothing here is 32-bit
Everything 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.
&& 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.
The 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.
Each part of the product is written down, including the parts that are not there yet.
Work already mapped out, roughly in the order it is being built.