What it looks like
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.The goal is to have feature parity with the good ol FoxPro
By leveraging golden tests against vfp9 we aim at having 100% compatibility. That is the mission.
What Visual FoxPro 10 would have been
Visual FoxPro stopped at version 9, and at 32 bits. This is the same language, rebuilt on a web foundation that brings the fox to the next level. Four pieces are what make that possible.
Using Nodejs as host give us 64 bit offsets for the DBF, lifting the 2 GB limit
There are really good projects, battle tested that brings vfp9 to 64 bits. We aim at something much bigger, an open runtime capable of loading 64 bit libraries and going above and beyond the closed source vfp9 limitations.
A compiler, and a machine built to run what it makes
Visual 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.
Forms rendered using React and a custom DOM tree
A 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.
Old libraries are battle tested, we support them
An .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 room
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.
Download
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.
Read the documentation
Each part of the product is written down, including the parts that are not there yet.
What is coming
Work already mapped out, roughly in the order it is being built.