Hacker News: boredjohnny

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Wed, 23 Sep 2026 21:00:36 +0000

I run a small consulting shop with a family member. We are a little bit tight on time but I'm willing to help with whatever you guys are facing rn.

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Wed, 23 Sep 2026 13:35:39 +0000

That is awesome! Checking it out. And the fact that is 100% compatible with vfp9 makes it a solid choice.

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Wed, 23 Sep 2026 08:41:54 +0000

Interesting! Yes, I would love to give it a try.

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Wed, 23 Sep 2026 08:40:08 +0000

That is the same experience that I had with manufacturing shops, they just keep using the tool if it works.

> And to the Author of the project. Thank You for making it. My pleasure

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Wed, 23 Sep 2026 01:52:23 +0000

Yeah sorry about that. Didn't thought about releasing it as this was a solution for my dad's friend shop that ran an old really old VFP project and didnt wanted/care to migrate. So I put together the site quickly using Claude. I might give it some human love next weekend

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Wed, 23 Sep 2026 01:51:02 +0000

Fair concern. MIT licensed, all source code on Github for audit. Only Nodejs + a Rust toolchain is required to compile it. On windows (for the FLL bridge) it needs Visual Studio C++ tools

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Wed, 23 Sep 2026 01:49:31 +0000

Hi Neat! you mentioned you guys are already on a rewrite path. That is the proper way forward and I recommend gathering as much information about the product and edge cases as possible. Document every business rule, every product decision. Handwaving aside, audit the Foxscript source code, clone it to a virtual machine or container. Any issue you face, feel free to post an issue on Github as I would love a few edge cases on the wild. As the Foxscript runtime relies on 64 bit offsets for the DBF/Memo, once a DBF (past the 2GB) is opened they can't be migrated back to old VFP9, so I recommend to test this carefully on an airgaped setup with tests DBF.

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Wed, 23 Sep 2026 01:35:41 +0000

Hi! thank you for the candid response.

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Tue, 22 Sep 2026 23:11:29 +0000

Because the same module runs in three places: inside the Electron IDE, in the shipped app, and in the test suite under jsdom, with no native build per platform. The other reason is the boundary itself: wasm exports can't re-enter, which forced the design where every side effect is yielded to the host and the VM is never on the stack while a dialog is up. That's what makes MESSAGEBOX not freeze the window. Perf isn't where these apps hurt, they're I/O and UI bound, and VFP itself was a p-code interpreter. The crate is plain Rust, the CLI runner is native, so a native build is a cargo flag away if it ever matters

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Tue, 22 Sep 2026 23:09:55 +0000

Thanks, this is the most useful comment here. FoxDev reads the DBC the same way VFP does, so today it inherits the hole exactly. The runtime is actually the one place it can be fixed. I would put in a hash of the stored procedure text into the built executable and refuse to run a container whose procs don't match. Adding it to the list. Would you mind if I quoted your comment in the issue?

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Tue, 22 Sep 2026 22:59:37 +0000

Funny enough the customer is one of my dads friends that has been running the same shop for 20 years, wanted bigger tables and keep milking that for the foreseable future. I wanted something simple, no jit stuff, no gc complexity. Just a stack based interpreter. Yes it was LLM assisted like most stuff nowadays.

New comment by boredjohnny in "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"

boredjohnny — Tue, 22 Sep 2026 22:57:25 +0000

bigger tables (2 GB cap) and no source code changes.

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

boredjohnny — Tue, 22 Sep 2026 21:00:30 +0000

Visual FoxPro stopped at version 9 in 2007. A surprising amount of it is still running, in 32 bits, because rewriting a 20-year-old business app is how you lose the business. A customer wanted to keep milking their app for the foreseeable future, so here it is: the same language on a new runtime (Rust, compiled to wasm, checked against the real vfp9.exe), tables no longer stopped at 2 GB, the old 32-bit .fll add-ins still loading, and lambdas, JSON and an HTTP server bolted on for good measure. Reports are not done and the builds are unsigned. MIT because why not?

Comments URL: https://news.ycombinator.com/item?id=49808023

Points: 485

# Comments: 270