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

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

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.

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.

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.

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

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

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.

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.

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

Just mentioning because you explicitly said builds are unsigned: I'm working on a (open source) signing solution supporting GitHub releases that is easy to use for both signers and downloaders. Let me know if this would interest you (not immediately putting link to avoid spamming).

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.

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.

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.

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)

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

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.

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.

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 :)

>1 commit 2 hours ago

>domain registered 7 hours ago

>ghost pusher named Dev

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.

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

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?

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.

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.

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

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

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!

That’s great! Nice work thanks for sharing. I’ve never heard of FoxPro but I’ve seen how businesses need some app for 30+ years. Cool to see this happen.

Great job! 32-to-64-bit conversions are always fun :) One question though. If this is intended for desktop, why bother with WASM at all? Do you gain anything other than less performance?

This is great! Next up: VB6

Microsoft should open-source FoxPro, at least some version of it, because as of 2026, it has no commercial viability (no ability for it to make the company money) compared to say SQL Server, Access and/or Visual Basic with the appropriate back-end database drivers. If Visual FoxPro V9 (2007) is too late because there are unexpired patents or other issues, then Microsoft should open-source an earlier version.

Even open-sourcing FoxPro 2.6a for DOS (the last DOS version, August 1994, > 30 years ago) would be better than open-sourcing no FoxPro version.

Fundamentally, FoxPro, at its core, is 4 things:

1) It's own low-level database engine

2) It's own SQL parser/interpreter/engine sitting on top of #1.

3) Simple (but very data-aware of the underlying data!) scripting language (based on dBase, referred to as "xBase" -- or more specifically the FoxPro dialect of xBase) sitting on top of #1 (except for the SQL commands, SELECT, INSERT, UPDATE, DELETE, etc., which sit on top of #2)

4) Form / GUI / Data-entry and Data-search Form Designers that exist on top of #1, #2 and #3. Basically a primitive (although very functional and elegantly simple) windowed App building environment.

Now, all of those 4 things could be replaced and/or outsourced to other open-source projects...

For example, to read/write/index/seek in FoxPro database files (the low-level database engine):

https://github.com/MPSystemsServices/CodeBase-for-DBF

I'm not sure if CodeBase comes with its own SQL engine/parser -- but if not, SQLite has a pretty good one which could probably be used with some modifications. If not, ANTLR has various SQL grammars for it floating around on the net (here's a quick blog post of someone using ANTLR to create a query language: https://markandrewperry.medium.com/using-antlr-to-create-a-q...)

For the scripting language, any scripting language could potentially work, but special attention should be paid to the way FoxPro variables are aware of data in underlying open tables in the current work area (SCATTER and GATHER commands and how they work, etc.), which is one of the unique features of FoxPro. (Also, for command / line / expression evaluation, you'd probably want to use or at least know about Dijkstra's Shunting Yard Algorithm: https://en.wikipedia.org/wiki/Shunting_yard_algorithm)

For the GUI / Form designers, well, any data-aware form-designing graphical toolkit could work, but of course, FoxPro has/had its own nuanced "flavor" of these.

Generically speaking, FoxPro is/was a database engine, SQL engine, very-data-aware scripting language and form/gui/app designer -- all rolled into one package.

I'd love to see an app where all of these components are open source, where there are clear interfaces between those components (separate compilation options for codebases, depending on which components you want), where the original FoxPro/dBase/xBase scripting language is used (because it was great!) and where any underlying database engine and/or SQL engine could be "swapped out" for any other (i.e., SQLite, Postgres, etc.)

Anyway, FoxDevStudio looks interesting in this space!

what was foxpro , for younger gen here

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 learned SQL with FoxPro on the Mac in the 90s. It was a great app.

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.

Ah yes, yet another reason not to bury the dead.

Cool - now do Lotus Approach

Hahahah this is too funny 8)

I wished almost it was terminal based

Give the fact this project sprung out of nowhere an hour ago, has one commit and no obvious history beyond that - I must ask, was this vibe-coded?