Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived

以下正文同步自 Hacker News，版权归原站所有，已转换为易读排版。

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-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 .fll

64-bit, end to endThe 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.

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.

Visual 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 count

The virtual machineA 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.

正文由 FLUX 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。