微软在 2007 年杀死了 FoxPro，不管怎样，这是复活的 FoxPro
文章摘要
这是一个 Show HN 性质的项目发布：FoxDev Studio，一个面向 Visual FoxPro 9 应用的 WebAssembly 运行时加 IDE，官网自称”写给 FoxPro 的情书”。作者 boredjohnny 在帖子正文里交代了来龙去脉：Visual FoxPro 在 2007 年停在第 9 版，但仍有数量惊人的 VFP 应用以 32 位形态跑在生产环境中，”因为重写一个 20 年的业务应用，就是失去这门生意的方式”。一位客户想在可预见的未来继续榨取自己那套应用的价值，于是有了这个项目：同一门语言跑在新的运行时上（Rust 编写、编译为 wasm、并与真正的 vfp9.exe 对照校验），数据表不再受 2GB 上限约束，老的 32 位 .fll 扩展库照样能加载，还额外加上了 lambda、JSON 和 HTTP 服务器。报表功能尚未完成，构建产物未签名，采用 MIT 许可证，”因为为什么不呢？”
目标是与原版 FoxPro 功能对等。 项目用针对 vfp9 的黄金测试（golden tests）追求 100% 兼容性。官网列出的数字是：运行时认识 Visual FoxPro 9 语言参考中的 1722 个元素，其中 1534 个有测试将其结果与原产品对比；只有 3 个名字还”没遇到过”，其余要么能运行、要么被有意忽略、要么被明确拒绝。截图展示了 VFP 自带的 Solution 示例项目被导入后运行的情形：123 个表单、7 个菜单、11 个类库，以及断点调试、调用栈、局部变量、监视窗口和数据库容器表浏览器。
“Visual FoxPro 10 本该是什么样”。 官网把架构拆成四块：
- 端到端 64 位：以 Node.js 为宿主，DBF 文件获得 64 位偏移量，突破 2GB 上限。作者承认已有一些久经考验的项目把 vfp9 带到 64 位，但这里的目标是做一个开放的运行时，能加载 64 位库、超越闭源 vfp9 的限制。
- 虚拟机：VFP 当年把程序编译成 p-code 并附带运行时执行，这里重建了同样的安排——一个用 Rust 编写、编译到 WebAssembly 的编译器和字节码解释器。编辑器的 lint 直接走运行时自己的编译器，所以”它标红的就是会失败的”。运行中的程序是一个 fiber：需要外部世界的东西时（消息框、模态表单、下一条记录）不会阻塞调用，而是 yield 出去，等机器离开栈后完成工作再把答案交回。因此
MESSAGEBOX()能暂停程序而不冻结背后的窗口，READ EVENTS等待时不空转，SetFocus能触发GotFocus，表单构建过程中Init的执行顺序也与 FoxPro 历来一致。 - 界面：运行中的表单是一棵带属性的活对象树，由 React 直接绘制。每个对象只监听自己，所以
THISFORM.lblGreeting.Caption = cMsg只重绘一个标签而不是整个表单。 - 32 位桥：
.fll是 32 位映像，64 位进程无法直接打开。SET LIBRARY TO会启动一个小型 32 位进程专门持有这个库，运行时与之同步通信（因为程序可能在表达式中间调用库函数，晚到的答案就不算答案）。项目用真实的库做了验证：加密库、FoxTools，以及用微软官方 API 示例构建的库。64 位的东西不需要桥，DECLARE ... DLL可以在同一进程内调用现代库。
FoxScript：同一门语言，更多空间。 以前写的代码含义不变，FoxScript 只在上面加东西：一种可以交给别人稍后执行的代码块（LAMBDA ... ENDLAMBDA），以及用已经懂你业务的代码直接响应 Web 请求的方式。官网示例里，FoxScript.Http.CreateServer() 创建服务器，用 lambda 注册 /api/v1/customers/:id 路由，路由里照样是普通的 SELECT * FROM customer ... INTO CURSOR，再用 FoxScript.Data.CursorToJson 返回 JSON，最后 Listen(8080) 加 READ EVENTS。”没有第二门语言，也不需要在旁边再立一个服务。”
下载方面，每次推送到 main 都会重建 nightly 并作为 GitHub 预发布版本发布，提供 Windows 安装包和运行时 zip、Linux 的 AppImage 与 .deb，源码在 GitHub 的 FoxDevCommunity/FoxDevStudio。路线图包括：补齐剩余的语言角落、报表设计器和报表引擎、一种能诚实面对 DBF 头部限制的超 2GB 表格式，以及把应用打包成终端用户无需任何设置即可运行的单一安装程序。
HN 评论精华
约 270 条评论，485 分。讨论氛围以怀旧为主，同时夹杂着大量对”AI 生成的项目和官网”的反感，以及一位前 FoxPro 团队成员抛出的安全问题引发的长篇争论。
先是满屏的怀旧。 很多人的编程生涯从 dBase、FoxBase、FoxPro 开始。meerita 说父亲用 FoxPro 做过好几个项目，”我们可能得买个软驱，翻出旧箱子才能找到它们”。tombert 说他可能是地球上唯一一个拿钱写过 FoxPro、Erlang、F# 和 ColdFusion 的人，第一份工作是给一家跆拳道馆维护 DOS 版 FoxPro 写的计费系统，”每次碰它我都恨透了”；结果 moron4hire 和 jhbadger 也都说自己给跆拳道馆或跆拳道教练干过同类活儿。Kuyawa 怀念的是那种体验：”在命令窗口里敲 Select * from customers，结果就漂亮地出现在浏览表格里，今天没有任何一门语言能做到。”networkOne 回忆自己用一个兼职月写了个面向加拿大房地产估价市场的 FoxPro CRUD 应用，第一年以每份 299 美元卖出 300 份授权。JSR_FDED 总结了它的历史意义：那是单个开发者靠一个工具就能交付业务解决方案、懂业务的人能自己写解决方案的时代巅峰，此后网络、安全、GUI、Web、部署全都变得复杂得多。
FoxPro 至今仍在支撑真实的生意。 rufugee 说他们公司每天运行 50 万行 FoxPro 代码，”是一门 5 亿美元生意的引擎”，AI 重写正在进行中，但对 DBF 的依赖让事情更复杂；他欢迎 foxscript 这类努力，并号召同病相怜者留言抱团。他后来补充说，最大的问题是 CDX 索引：100 多个 DBF 文件、600 多个客户端同时访问。ksec 说某个小众行业的行业标准软件就是 VFP 写的，他特意打电话问了一下，2026 年仍在用，单家公司年收入超 4 亿美元，整个行业超 20 亿美元，”如果没坏，就别修”。EvanAnderson 爆料俄亥俄州某个获准使用的选民登记数据库就是 VFP 写的，保存着选民名单、地址和签名扫描件，最近为满足州务卿要求加了 TOTP 多因素认证，但任何用这个软件的人都能直接打开共享文件夹里的 DBF 文件，”我只能摇头”。
前 FoxPro 团队成员指出了一个根本性的安全问题。 mikestew 自称 20 多年前在微软 Fox 团队工作时亲自提交过这个 bug：数据库容器（DBC）要有用就必须对所有用户可读写（没有权限机制），而 DBC 的存储过程能运行任意 FoxPro 代码（包括 Win32 调用），并以明文存在一个 memo 字段里。数据库只是文件系统里的文件，用文本编辑器就能修改 INSERT 触发器，绕过运行时的所有检查，”FoxPro 只会执行它在里面找到的东西”。这个 bug 不重写数据库引擎的大部分就修不了，他的建议是尽快把 DBF/DBC 迁到某种 SQL 数据库。作者 boredjohnny 回应说这是”这里最有用的评论”，FoxDev 读取 DBC 的方式与 VFP 完全相同，所以目前原样继承了这个漏洞，而运行时恰恰是唯一能修复它的地方——他打算把存储过程文本的哈希嵌入构建出的可执行文件，拒绝运行不匹配的容器。
但不少人不认同”漏洞”这个说法。userbinator 说：”如果你本来就被设计成拥有完全访问权，那就谈不上’巨大的安全漏洞’。”EvanAnderson 解释 FoxPro 是进程内数据库引擎，像 SQLite 或 BerkeleyDB 一样以运行应用的用户身份访问数据文件，任何不改变这一架构的权限补丁都没抓住重点。lelanthran 打了个比方：那个年代本地应用的权限系统不是最高安全级监狱的大门锁，而是卧室门锁，只防止有人误闯。mikestew 回应说大多数情况下”完全访问数据”并不意味着”能运行任意代码”，而这里恰恰意味着，这是人们意想不到的，所以他称之为漏洞。mamcx 则认为安全模型由部署方式和使用场景决定，而不是由存储类型决定。
“又一个 vibe coding 项目”的质疑。 whalesalad 说：”这些 vibe coding 项目很难让人认真对待。我能感觉到 LLM 在向我推销。”ravenstine 说这类项目官网无一例外地让自己看起来比实际更有野心、更成熟，一个几小时大的项目就配着几年前只有成熟且有营收的项目才会有的网站，”如今一个简陋的网站或一份手写的 README 反而是更可靠的信号”。opengrass 列出事实：仓库只有 1 个提交且是 2 小时前、域名 7 小时前注册。roywiggins 摘出官网上的句子——”Visual FoxPro 是一个 32 位程序，这一点决定的东西比看上去更多”、”编辑器通过同一个编译器检查你输入的内容，所以它标红的和运行时拒绝的不会彼此偏离”——问道”谁会这样说话？”rayiner 好奇模型为什么爱先抛出一个事实再揭示其意义，captn3m0 认为是 RLHF 评审者偏爱，antonvs 则猜测源于训练数据里大量营销文案和 LinkedIn 帖子式的”钩子”写法。作者承认官网是用 Claude 快速搭的，因为这本来只是给他父亲一位朋友的店铺做的方案，那家店跑着一个非常老的 VFP 项目、不想迁移，”下周末也许会给它一些人类的关爱”。作者在回复中也承认代码是 LLM 辅助完成的。dang 还亲自出面，请作者不要在 HN 发布 AI 生成或 AI 编辑的评论，并说明项目本身可以提交，但站内文字应完全由人类撰写。mdmower 的判断很直接：点赞大概都来自怀念 FoxPro 开发岁月的人，而不是认可这套看起来完全由 AI 写成的网站、文档和应用的质量。
技术问答。 ndiddy 问为什么重写整个运行时反而比重写应用更让人放心，作者的回答简单明了：”更大的表（2GB 上限），而且不改一行源代码。”Pannoniae 问桌面应用为何要用 WASM，作者解释同一个模块要跑在三个地方（Electron IDE、交付的应用、jsdom 下的测试套件），无需为每个平台做原生构建；而且 wasm 导出不能重入，这迫使所有副作用都 yield 给宿主，正是这让 MESSAGEBOX 不会冻结窗口；这类应用的瓶颈在 I/O 和 UI，VFP 本身也是 p-code 解释器。wila 提醒早就存在一个由知名 VFP 开发者做的 64 位版本 VFP Advanced，且与 vfp9 100% 兼容，作者表示会去研究。brookfinch61028 追问 Linux 版能保留多少功能，因为大量 VFP 代码通过 CREATEOBJECT 驱动 Excel，而 .fll 桥是个 32 位 Windows 进程。
RAD 工具的消逝。 帖子引出一长串关于快速应用开发（RAD）工具的讨论。jordand 说 Microsoft Access 至今活着，三年前 32 位版还加了大地址感知支持；post-it 感叹 Linux 和 Mac 上居然没有通用的 Access 替代品。aleph_minus_one 列举了开源尝试（Tcl/Tk、Lazarus、LibreOffice Base、Glade），并解释 RAD 的典型用户是懂一点编程的领域专家，而开源社区吸引的是真心热爱编程的人。progmetaldev 认为微软推出 XAML/WPF 后”把 RAD 里的 R 拿掉了”。whartung 补充了一段历史：微软收购 FoxPro 后并没有一刀捅死它，而是开发了好几年，收购带来的核心数据库引擎后来演变成了 Access 背后的 Jet 引擎。jasode 则泼了冷水：他当年真的在 FoxPro 和 VB 上干过活，没有那么美好的怀旧——VB 项目里每家公司都有一堆第三方 VBX/OCX 控件，FoxPro 连打开 zip 都要花 300 美元买库构建工具包、用 C 手写解析器，今天的 Python 或 C# 用内置模块就能搞定。peter_d_sherman 呼吁微软至少开源某个版本的 FoxPro，哪怕是 1994 年的 DOS 版 FoxPro 2.6a。