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

Never installed it myself, but the following might help in getting it set up:

https://support.west-wind.com/Thread5YZ172FPW.wwt

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

The solution I'm working on is https://www.asfaload.com. To get a quick idea, see the videos, incl. demos, at https://www.asfaload.com/videos/. The code is at https://github.com/asfaload/asfaload. There's no binary executable published yet, so you'd need to compile. However, I'm very interested to help you on the setup and get your feedback. Don't hesitate to contact me by mail on the address found in my profile ( ${my_hn_username} gmail address) and I'll be happy to help!

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

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

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

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.

Do you do consulting in this space? I'd be interested in having some discussions...

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.

Would love to have a conversation. Drop me an email at rufugee@proton.me. Looking forward to it.

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

Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.

Of course, it's impossible to know for sure what was LLM processed or not, but your comments are getting classified that way.

(The project itself is fine, of course, to submit to HN. We just want text on this site to be entirely human-written.)

Hi! thank you for the candid response.

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?

Feel free to quote me, contact info in profile if needed.

EDIT: sorry, I originally just skimmed your comment. I was unclear in my original comment: the files can be accessed and “hacked” from the file system with a text editor. (And a bunch of deleted stuff because I misread your comment.)

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.

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