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?
My father built several projects in FoxPro. I was too young in the ’90s to remember much of it, but I’m sure he’ll be super happy to check this out. The kicker is that we’ll probably need to buy a floppy disk drive and dust off some old boxes to find them.
I might literally be the only person on earth that can honestly say I have been paid to write FoxPro, Erlang, F#, and ColdFusion.
My first software job was at a Tae Kwan Do studio who ran their own billing department, and the entire billing half was some weird custom thing written with FoxPro. Not Visual FoxPro, I've never actually used that, but the old school DOS stuff.
I absolutely hated every time I had to touch it and I had hoped that it would die in a fire. I hope Visual FoxPro sucks less.
The low barrier to entry, high developer productivity, and
bespoke and "highly conforming to proprietary business processes" nature of resulting applications are all really cool, but man, it sucks when one of these systems outgrows the capabilities of the underlying platform.
I shudder at the though of businesses trying to access DBF files on "network drives" across the variety of shitty overlay network technologies that are the norm today. Seamless remote access to applications is the exact recipe Visual FoxPro apps fail at.
It looks cool but I wouldn't want actually work around apps built in it. It would be cool if a client/server database could be transparently shoehorned in to it.
So hard to take these vibe coded projects seriously. I can feel the LLM selling it to me. I don't want to suggest the code is bad or it doesn't work or doesn't have awesome features... but ai built landers are just so smelly.
This is awesome! Having had to deal with ancient file formats knowing that there are renewed tooling that's not binding to legacy OSes that you can't no longer find viably is great.
Now, who's open sourcing and reviving FileMaker that Apple killed?
A company I worked for has run VFP up until the last few years. I cut my teeth professionally with it on ETL processes. It moved data around like nobodies business!
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?
I feel like the business apps are an easier rewrite these days rather than imperfectly recreating the runtime environment.
Now your customer has two problems instead of just one.
My father built several projects in FoxPro. I was too young in the ’90s to remember much of it, but I’m sure he’ll be super happy to check this out. The kicker is that we’ll probably need to buy a floppy disk drive and dust off some old boxes to find them.
Clarion and Paradox thought one of them was going to win the tontine.
R:BASE is still around
I loved visual fox pro as a kid (~10). I made little UIs to open my favorite sites and files.
I might literally be the only person on earth that can honestly say I have been paid to write FoxPro, Erlang, F#, and ColdFusion.
My first software job was at a Tae Kwan Do studio who ran their own billing department, and the entire billing half was some weird custom thing written with FoxPro. Not Visual FoxPro, I've never actually used that, but the old school DOS stuff.
I absolutely hated every time I had to touch it and I had hoped that it would die in a fire. I hope Visual FoxPro sucks less.
The low barrier to entry, high developer productivity, and bespoke and "highly conforming to proprietary business processes" nature of resulting applications are all really cool, but man, it sucks when one of these systems outgrows the capabilities of the underlying platform.
I shudder at the though of businesses trying to access DBF files on "network drives" across the variety of shitty overlay network technologies that are the norm today. Seamless remote access to applications is the exact recipe Visual FoxPro apps fail at.
It looks cool but I wouldn't want actually work around apps built in it. It would be cool if a client/server database could be transparently shoehorned in to it.
Cool - now do Lotus Approach
So hard to take these vibe coded projects seriously. I can feel the LLM selling it to me. I don't want to suggest the code is bad or it doesn't work or doesn't have awesome features... but ai built landers are just so smelly.
This is awesome! Having had to deal with ancient file formats knowing that there are renewed tooling that's not binding to legacy OSes that you can't no longer find viably is great.
Now, who's open sourcing and reviving FileMaker that Apple killed?
A company I worked for has run VFP up until the last few years. I cut my teeth professionally with it on ETL processes. It moved data around like nobodies business!
I work at a place with CRM that runs on visual fox pro. :)