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

I know there are still a few niche industry that has an industry standard program written in Visual FoxPro, and I remember as pre COVID 2019 they were still using it. ( Edit: I just called and asked, still using it as of 2026 )

Niche but no small business, commodity with over $400M USD annual revenue, the industry together that is easily $2B+.

If it is not broke, don't fix it. And there are industry that is extremely conservative in anything software, they will just keep it running for as long as they could.

I used to be sad that we don't have something better to replace these antique software. Now I have come to appreciate it, mostly because newer software haven't show they have manage to add value in the slightest. And most of the time they simply don't work as well.

Delphi, Visual FoxPro, Visual Basic, Flash. I used to think one day we will have something that is not only faster, easier and scalable replacement of those. Instead everything went more technical, more complex, enterprisy and non-user friendly.

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

Here’s my problem with reviving FoxPro in any form: there’s a huge security hole in the Database Container (DBC) design. For DBCs to be useful, they must be read/write to all users (there is no permissions scheme). DBCs have stored procedures that can run any FoxPro code, including Win32 calls made from the FoxPro runtime. The stored procedures are stored as plain text in a “memo” field. Do you see where this is going? With a little technical knowledge, one can modify that INSERT trigger to whatever you like. EDIT: as the DB is just files in the file system, modifications can be made using a text editor, bypassing any checks in the FoxPro runtime. FoxPro just executes what it finds in there.

My recommendation is to get rid of the DBF/DBC files and move to a SQL DB of some flavor ASAP. If you have the source code, use ODBC or OLE DB to point to a server.

Source: filed that bug over 20 years ago when I worked on the Fox team. No, it wasn’t going to get fixed without rewriting large parts of how the DB engine worked.

I worked with a physician's office in 2006, and the lead physician had cobbled together a system for patient tracking using Visual FoxPro. It was a monstrosity, and using it over a network drive gave all sorts of file locks and issues with multiple people changing the same record (usually the physician and front of house staff when checking the patient out).

I finally got the physician to switch to a proper client/server architecture using .NET WinForms and ASP.NET RPC calls. All issues went away, and I was even able to allow staff members to edit the interface to set what mattered to them most at the top of the application, by building the lab testing form in XML so they could move the X/Y coordinates to where they wanted them. It wasn't even a feature I had thought of, just a physician looking through the technology and figuring out how it worked (luckily the business and security logic were on the server, so a bad actor could only have destroyed their own local copy of the app).

My goodness, a blast from the past. Such a glorious time to be a programmer... every single business needed a database to do their simple little daily chores, the coding was insanely easy (just a bunch of CRUD process), and the difference it made to the customers was night/day... hence, you could charge thru the roof.

I wrote a simple little CRUD app in FoxPro, for the Canadian real estate appraisal market, which took about a part-time month to create, and first year, sold 300 licenses at $299 a pop.

Ahh, memories of a simpler time.

Flashback. When I was an adolescent, the dBase and Fox products were my first paid software development, and they were surprisingly accessible to even kids.

I was only supposed to help assemble computer furniture, and maybe install networked Unix and PC software, but the retired Marine my mom worked for thought I had potential. "Hey, Kid", he would say, we need to modify this dBase vehicle fleet insurance database to support more vehicles; figure it out. Here's the manuals for C database library, and Microsoft C, I'm evaluating; figure it out. We need to migrate between accounting systems; here's a sample .DBF of the target schema, here's how you generate a full dump from the legacy minicomputer, use this editor called Emacs to clean up the dump for import, once you figure out the schema mapping; figure it out. I also bought an older dBase product, and then a Fox product, for home, and figured out how to build a few fancier systems.

(Then I kept working, and there was a period when all employers either wanted me to figure out something, or were favorably surprised when I soon did, thanks to formative influences of figure-it-out mentors. Then a break to get belated formal degrees, then being surprised after that pause, when job interviews were suddenly Leetcode-like, and they didn't seem to want me to figure it out, but wanted a rehearsed ritual performance conforming to a big-corporate sanctioned set of rules, and apparently the Marine hadn't written a book to counterbalance that awful green book. :) )

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.

Hey, I got to mention this recently! One of my bizarre claims to fame was writing this little tool[0] a few employers back to convert Visual FoxPro database files to PostgreSQL as part of a migration. For a while we had to run it as a cron job so that people could to data entry in an old VFP app but others could run fast reports on our web app with a postgres backend. It wasn't pretty, but it worked great and helped us get off that ancient stack.

[0]https://github.com/kstrauser/pgdbf

There's been a 64 bit version of FoxPro for years and years [1].

No, not the official VFP as released by Microsoft, but a version made by a well known VFP developer.

Besides that I do know of some developers actually using this for building their software.

No connections here, just know that it exists and is used and well before LLMs became the answer to everything.

[1] https://www.baiyujia.com/vfpadvanced/f_vfpa_about.asp

"The IDE, on Visual FoxPro's own sample projects. Every picture is a real session." starting to have involuntary revulsive twitches from Claude prose

Please stop using AI to write it gives a headache. Just go with simple 2 line sentences you can write on your own or even dictacte it if youre lazy.

> Visual FoxPro is a 32-bit program, and that decides more than it appears to.

Has anyone studied what in the models causes this sentence structure? Is it some consequence of the architecture that leads it to blurt out a fact and then only later the significance of that fact?

Microsoft might have killed FoxPro but even in windows 11 they still have the icon for it in moricons.dll where it will live presumably forever in every version of windows Microsoft ever releases.

Great job with this project, I bet there are VFP apps still running or even DOS FP apps.

This takes me back to the first commercial software i ever worked on around 19 years ago, it was an accounting software written in Visual FoxPro. It's a super easy language to get started with programming and the fact that you can drag your widgets on the screen helps a lot. I remember using hungarian notations too. In hindsight that's both good and bad, because the moment you move to another language that doesn't offer an IDE where you can drag widgets with your mouse on the screen to position them and you have to work with containers, programmatically, you quickly realize how little you really know about creating UIs with forms. I don't think i had an opinion back then if VFP was good or bad but I remember the IDE would crash when you tried to build your project sometimes with a pop-up that would say "Catastrophic failure!". I always thought that was super funny and to this day i still have the screenshot. I think about a year or so before they killed it, they releases SP2 which was a bit more stable.

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.

My father in law did database programming for small businesses using FoxPro. It was pretty cool, it created the executable and you could host it on any Windows file server IIRC. I think it also may have had some server functionality built in too. Anyways, it was fast if the database was designed correctly and allowed for easy setup at the clients offices. I think before that he was using a product called Clipper.

The home page for Foxscript is perfect IMHO. Loads fast, well written, easy to understand, looks great.

My first ever "paid" consulting job was building a dBASE application.

"Paid" in quotes because I was about 10 years old at the time and the work was done for my mother in her capacity as a government employee. What she could do, though, was find a surplus shrinkwrapped copy of dBASE III Plus that I was allowed to keep when I was done.

Neat! I tried to do the same for Filemaker Pro 10 (with Fable). Bit couldn't push it beyond 50% functionality.

It occurred to me recently that with AI/ML, we can basically keep any and all software going, no matter if its original authors retire it .. its getting to the point where an AI can reliably parse the bytes and apply whatever ABI is defined for the platform, and then .. add features, fix bugs, and so on.

Are we witnessing the end of the age of source code? In many ways, the signs are on the horizon that we are.

My first real job was 2006, turning a Visual FoxPro application into a Web Application using ASP.Net 1.1 Web Forms and VB.Net.

With that said, I've never actually used FoxPro. I only had a database as the contract for what my web app was supposed to do.

>1 commit 2 hours ago

>domain registered 7 hours ago

>ghost pusher named Dev

All these years later, Microsoft Access is still alive and kicking, and just three years ago, the 32bit version got Large Address Aware (LAA) support! Technically my very first software job was writing VBA in Microsoft Access for a few weeks and they're probably still running it (there's no drop in replacement for it or cheap way to migrate away)

Can LLM access FoxPro programmatically, or is the file format easily parsable? Most of FoxPro apps are likely fairly simple CRUD apps. It would be trivial for a modern AI to transcode it to a web based client server solution.

I loved visual fox pro as a kid (~10). I made little UIs to open my favorite sites and files.

I miss the VB6 days. Simpler days with worse options than what we have today, but being able to drag a button onto a canvas, double click it, wrote the code behind it, and then build to an executable was lovely. I wish I could do that today with macOS but everything is so complicated these days. AI helping.

I haven't used FoxPro but I have had plenty of exposure to tech with a similar 'feel' - Excel and Word documents scripted to the gills with VBA, eventually C#, and mutating into new and kinds of horrors.

It always starts simple - you wanna build just a simple CRUD where the entry is a form that goes into the table.

Then the complexity grows, and your table has to reach out to other services, call APIs etc. etc.

The 'convenient' primitives, that did 90% of the things that need doing can't do the last 10% - so you drop down to VB, which is exactly like regular programs but worse. It also doesn't interact well with the rest of the system, so you have to rewrite adjacent stuff in VB too.

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...

Oh nostalgia, dbase, clipper, clarion, foxbase, delphi, I loved VFP so much, not for the language but for the tools, the screen designer, the db browser, the sql queries, all that power and user love was dumped in the trash can for the travesti that was .net at the time

I learned VB.net, C# and even F# to see if they surpassed in any sense my beloved VFP but no, I felt so betrayed I decided to migrate to a galaxy far far away and never look back, 25 years ago (a time where exes and single user apps where the norm for my clients, then came multiuser and external db storage, then the web took over)

This looks promising, I'll give it a try. If I asked AI to fork it, I'd change the language to modernize it a bit (uppercase now looks like cobol written on a punch card)

Edit: On a second thought, I'd fork it in Swift (with the help of AI of course) and use it in MacOS for single user desktop apps. It would serve a single purpose much better than xCode does

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.

OMG what a blast from the past. We were taught FoxPro in school in 2002 for some reason. Not even Visual FoxPro, the old school DOS version. It taught me a lot about scripting and I remember helping out a medical rep who had built a FoxPro app to manage his business while in college.

I have learnt programming watching my mom code in foxpro (using el editor) in the early 90s. I would sometimes correct her missing parantheses haha. She made all UI out of box drawing characters, unbelievable amount of work compared to today.

Good lord. I remember having to convert Visual FoxPro "programs" to PHP+MySQL way back in 2011. That was actually a lot of fun.

This is fascinating. The author did great work here.

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.

Ah the xBASE languages, I was a big fan of them and Clipper 5 helped a couple of side gigs during school years.

Never got to use FoxPro though, but followed along in magazine articles and such, great to see this kind of tech going on.

Someone really missed those `.dbf` files. Curious if the report writer is still a nightmare or a nostalgic dream.

The main kick is that there is not a way to "rewrite" a foxpro app without tons of stuff along the way!

(Example: You can ship an app that internally run `CREATE REPORT` and the report builder show up. You can invoke the debugger (that as I remember is the best I used a zero alternatives as good existed)) and so on

haha, I used this exact example in sales calls to make the case against app modernization. Sometimes, you just need the stuff to keep working, with $20-and-a-roll-of-duct-tape-level budgets.

My proposal was proxy layer sitting in between, running on something like k8s and written mostly by an LLM to provide a safe interface to queries against foxpro, with ratelimiting, query parsing, rest, whatever other business logic you want.

I am appalled at the fact it's still out there, but there is even older, more Archean stuff out there running literally the entire world :)

Wow, FoxPro! Used to build some gnarly inventory systems with that. Good to see it kicking.

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?

For vibe coded open-source projects, I believe the prompt session/history should be shared as well.

Since vibe-coding solved the issue of manpower, why stick to Electron and js frameworks?

What issues were your customer running into that made a 64-bit FoxPro necessary? What makes you more confident in rewriting the entire runtime the app runs inside of than rewriting the app itself? That seems just as risky if not more.

Why does every AI written project website make it sound like it's going to kill all your enemies for you and get you all "the bitches"? This is true power. Unforseen by human eyes thus far. Your manager will tremble in fear.

I would absolutely love to interact with a demo program made using this FoxPro.

Clarion and Paradox thought one of them was going to win the tontine.

Our high school taught FOXBASE and I immediately fell for it. I didn’t make anything real with it, though, but it was my first official language and I dreamed big back then.

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!

Goddamn this brought me back to my childhood with FoxPro books on my dad's bookshelf when I was a child. Thanks for that, necromancer.

Ugh. My first job was rewriting foxpro. Bad memories.