We run 500 KLOC of FoxPro at my company, daily. It is the engine that fuels a $500M business.
I hate that it's the hand I'm dealt, but aside from AI rewrites (underway), there's no good answer. It's complicated by our reliance on DBFs.
I welcome efforts like foxscript and anything else in this space. There are still a significant number of FoxPro apps out there and no one has a good answer. If you are struggling in this space, leave a comment here. I'll reach out to you. Strength in numbers...
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.
DBFs tend to be the easy part, in my experience in a similar company (not as much revenue.) The spec is simple enough that one can write a reader/writer in an afternoon, even before AI.
My biggest challenge is the speed at which calculation heavy business logic can operate in FP, even on network shares, as long as they're optimized for IOPs not bandwidth. Trying to adapt similar data access patterns to a networked RDBMS will kill you with round trip and connection overhead. Converting that logic to set-based operations or stored procedures means altering logic and all the risks that entails.
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
I would welcome a community effort. There are many (?) companies still relying on FoxPro. Vibe coding a solution is feasible these days. We've vibe-coded a few from FoxPro to Ruby on Rails with great success. I'm no longer stressed about the future... just the timeline.
It's come a LONG way in user friendliness in 10 months. Combine Omarchy with a LLM and you can literally change any behavior you want in minutes. I have heavily customized mine, but have been able to remove some of those customizations on Quattro because upstream incorporated similar features.
I am running it on the Framework 13 and 16. Both are awesome devices, but I'm partial to the 16. Beautiful screen, great keyboard, and I can easily swap in an NVIDIA card when I want.
Battery life isn't the best in this beast. I'd love to try a Dell Panther Lake laptop and may end up with one in the near future. DHH reports Apple Silicon-ish battery life.
I hate that it's the hand I'm dealt, but aside from AI rewrites (underway), there's no good answer. It's complicated by our reliance on DBFs.
I welcome efforts like foxscript and anything else in this space. There are still a significant number of FoxPro apps out there and no one has a good answer. If you are struggling in this space, leave a comment here. I'll reach out to you. Strength in numbers...