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.
>, 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.
A person's perspective on the older dev tools being "superior" to today's newer tools depends on the things they want to build.
I had jobs working on Foxbase/FoxPro for DOS and migrated those apps to FoxPro for Windows, and Visual Basic 3.0 to 6.0 ... and I don't look back at those with the same positive nostalgia.
Classic VB was "simple" but every project at each company had a different hodge podge of 3rd-party VBX/OCX add-on controls to do anything non-trivial. E.g. 3rd-party calendar date picker, report writer, etc. VB didn't have a decent datagrid so everybody bought a 3rd-party one. In contrast, C# WinForms standard controls included a usable datagrid with data binding out of the box.
In a FoxPro for Windows project I was working on, we needed to open .zip files. FoxPro didn't have that functionality so the company paid an extra $300 for the FoxPro Library Construction Kit[1] and I hand-coded a .zip file parser in C Language to be called by FoxPro code. Instead of FoxPro dev work being simple, it's complex! Today's Python or C# can trivially open .zip files with builtin modules and functions so devs don't waste time on writing low-level C code or use 3rd-party libs.
With old 1990s tools, you can't do "simple" tasks such as getting a UTC timestamp, use a regex expression, or retrieve a web page with an http call, etc without calling Win32 API functions or 3rd-party tools.
If one wants to do things beyond the limitations of classic VB/FoxPro, the newer dev tools like Python/C# etc absolutely do make things easier and faster.
This is only tangentially related but I often wonder about the nature of software and whether we made a mistake "standardizing" as much as we have.
I say this not because you're wrong - I'm sure that using built-in modules for .zip parsing is faster and easier! - but rather because I don't know whether or not it's worth knowing how to do that. In the AI days right now there's argument being had about whether learning any coding at all is valuable. My gut says it is, but I've also spent years learning before AI, so maybe it's a sunk cost fallacy.
Regardless, my feeling is that we haven't found the balance between what's worth making every programmer learn/implement themselves, and what's worth abstracting away. Maybe implementing a .zip parser gives you some kind of secret wisdom that makes your future work better?
I'd hardly consider it secret, or wisdom, but I can think of many problems involving ZIP files I've solved in the past that it wouldn't even have occured to me to pose if I hadn't understood the broad structure of ZIP files as a series of metadata/data pairs followed by an index containing a mostly redundant copy of the metadata.
In other words, solving the right problems, however inefficiently, will always be more useful than solving the wrong problems efficiently.
At the time I worked for an organization which pretty much had an unlimited budget for development and had therefore purchased just about every VBX bundle. They also had a solution with about 90+ complex forms - and no standards, so each developer of each form would pick whichever VBX control that "pleased their eyes". Which was "fine", until about 50% of those VBX control vendors simply did not offer an OCX upgrade in a timely manner - or in many cases simply folded/stopped entirely...
(The next nightmare was transitioning to what was supposed to be a more loosely-coupled COM type architecture, where each form could be dynamically loaded - except, referenced dependency tree and "breaking-binary-compatibility" during weekly "clean builds" ended-up taking sooooo much time... Thanks to a tool from a MSFT employee via their consulting service called "VBBuilder" (think of essentially "make") finally helped reduce that manual effort from a full day to just minutes...)
I don't recall that I ever did this with a FoxPro app. I used to make part of my money porting or cloning bespoke small business apps to OpenOffice Basic or OpenOffice with its Python integration. Visual Basic, QuickBasic, MS Basic PDS, TurboBasic, MS Access, and Turbo Pascal apps I'd replace with the integrated languages of the office suite.
Some of those originals used DBase III or DBase IV libraries. Some used bdb libraries. An awful lot used fixed-width fields designed into the application itself. Many of them I wouldn't have the source for, so I'd have to reverse engineer the data file format a little and then write a proper schema for a real database.
Sometimes the hardest part was getting the forms to look acceptable to employees at my client who were used to a curses style interface.
A big software for simulating the economic balance sheets of life insurance companies moved many years ago from using FoxPro under the hood to CSV files and sold it as a huge improvement. I don't think anybody was convinced by that, but vendor lock-in makes companies accept such regressions.
Maybe someone proposed Postgres and they said well who is going to support it. And then they'd have to pay some company to show they have postgres support anyway.
I once worked on maintaining an accounting package that exported to csv. At one point there was a bug where if the notation for a transaction included a single unmatched quote, the rest of the exported data silently disappeared.
The depressing part wasn’t finding this bug (in a very mature codebase), it was painstakingly explaining what the problem was and how to fix it.
All these tools are nice for a single developer. But they fail to scale for teams where you want a distributed version system, automated tests and CI/CD pipelines. Also you want to reuse code via package management systems. And a single code base for several target systems (cross compilation , electron) is also nice. I believe the mentioned tools offer none of this.
> But they fail to scale for teams where you want a distributed version system, automated tests and CI/CD pipelines.
I don't think this is true? Certainly you could have done those things with Delphi but it pre-dated DVCS and CI/CD being common concerns.
> Also you want to reuse code via package management systems.
Again, these tools pre-dated package management systems being in common use because they pre-date internet access at any sort of bandwidth being a reliable assumption. No reason they couldn't have one. Perl did at the time, which I mainly put down to it being in common use where internet access was a reliable assumption, but very little else did.
> And a single code base for several target systems (cross compilation , electron) is also nice
You can absolutely do this with Lazarus, which picked up where Delphi left off. Flash also counts here.
Think Flash (eventually) had most of these. That said, not all software development needs to happen at the same scale and not all software authoring environments benefit from the same tradeoffs vis-a-vis complexity, collaboration, accesibility etc. the success of Flash as a platform for independent game devs shows that different markets are better served by different tradeoffs.
It feels small to some people in 2026, depending on the business type and the field. Most businesses are small businesses, though. It actually approaches 100%. This is under the SBA's definition as of not long ago. There are limits on earnings, number of employees, or both for what can even be considered a "small business" that vary by industry. They are as low as $9 million revenue or 100 employees, although some industries have much higher ceilings. https://legacy.sba.gov/sites/default/files/2023-06/Table%20o...
The average annual revenue of a small business in the US in 2026 is around $1.2 million. The average headcount is about 11 people. About 46% of employees in the US are employed by small businesses. In 2024, about 64% of new jobs were created by small businesses. About 61% of new jobs from 1991 to 2025 were created in small businesses.
Well, commodities are commodities, and it was said it was a niche market. The company itself seems pretty big to me, relatively. $400m in a market of about $2b means they fill a pretty substantial part of the available market.
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.
One of the Ohio Secretary of State's "certified" (wrong terminology, but you get the idea) voter registration databases used by various county Boards of Elections is written in VFP. The software maintains the list of voters, their addresses, and scans of signatures.
Recently it had TOTP 'MFA' added to comply with a Secretary of State mandate.
Anyone who uses the software can just open the database files directly. They're just DBF files in a shared folder on a file server. All the users have to have read/write access to the files or the application won't work.
seen this exact pattern in small business FoxPro setups too, DBFs on a share are one dropped SMB connection away from a corrupted index. if you're stuck maintaining something like this the least bad move is nightly copies of the whole folder to a second box, and actually opening that copy in the app now and then instead of just checking that the file sizes match.
This is an _excellent_ example of what anyone who has been professionally responsible for backups means when they say "it's not a backup until you've restored from it, booted into it, opened the app, and accessed the data"
There's still so much software out there that is an absolute lynchpin to a business that will never have the kind of durability/compatability many take for granted. The only thing that has changed in the past 2 decades is the operating system running the VM. In 2026 they are still yelling across the office or exchanging phone calls when one has finished and signed out so that the other can sign in and pull the updates.
It often isn't taken seriously or is written off because it's a "small business", but those 2-8 people run a book of business that clears this comment thread's lifetime earnings annually.
Exactly. It's not a security hole. It's just the architecture of the program.
It seems like many people have a hard time understanding this, including developers.
Any attempt to add any kind of permissions, security, etc, without addressing the nature of the architecture (that the database engine runs in the same address space / security context as the UI) misses the point.
Further along those lines, it was a different world when the code was created.
Trust was a thing back then. Spam was something that came out of a tin and was made of dead animal. And passwords were limited to eight ASCII characters.
And as such, bolting security onto something that was designed inherently to be security agnostic is going to be a recipe for failure.
It had absolutely nothing to do with trust. People still worried about the security of their databases. Businesses understood perfectly well that their electronic records were just as sensitive as their paper ones. But the server closet had a lock on the door, and no wire connecting it to a global network of mostly scammers. It was just as secure as the paper records.
No, it wasn't. The reason I even raised this bug to begin with was not because of some nefarious $BAD_COUNTRY hacker getting yer dataz from far away, it's because you have to worry about your own users first. I'd guess that any consultant doing the kind of work FoxPro excelled at (LOB apps) has found some clever boy or girl who discovered they can poke at DBF files directly. Long before internet connectivity was common, one still had to worry about your own coworkers futzing things up.
Well, on a different note, if you have a scripted language application, you typically can edit files and bypass whatever you want on the application. In fact, I'd bet most modern software isn't signed; and even if it is, sometimes the libraries that get compiled in into that signed binary... aren't.
I can change the behaviour of many/most applications by just having read/write access to files; Can you give me examples of mainstream applications that are resistant to filesystem tampering when eg.you have install access? Maybe I'm missing something.
With a permissions system that’s meant to enforce security? I hope not.
I’m not a FoxPro user and so maybe these are single-user/single-host installs, where the user can only destroy their own data, and permissions are a pretend feature. In which case, carry on.
> With a permissions system that’s meant to enforce security? I hope not.
There's different needs for a permissions system.
You're thinking of it as "lock to the main entrance of a maximum security prison". Think of it more as a lock on a bedroom door: it's not there to withstand a SWAT assault, it's there to keep people from accidentally walking in.
All local applications (which were all applications in the era we are talking about) with permissions were sold to companies on the understanding that there was no real security.
Hell, even the networked products at the time had no real security :-/
Sure. The user would need to logon as the FoxPro user to use the application. At that point, having the FoxPro user credentials, the user can manipulate the FoxPro data files directly without using the application.
The rub here is that FoxPro is an in-process database engine and accesses its data files with the security context of the user running the application. It doesn't have separation between the database engine and the UI like a client/server database would. Think of it like SQLite or BerkeleyDB.
Architecturally users who use the application need full read/write access to all the data files for FoxPro to work.
Well, I had to call it something. File system DBs were a problem long before FoxPro’s DBCs, yes. Yes, it’s an architectural decision. Sharp cookies would just modify the files directly. But that would just trash data (or bump my hourly rate in the HR DB). Most of the time, “full access to data” doesn’t necessarily mean “run arbitrary code”. In this case, it does, which I don’t think folks expect, hence “hole”.
And that would be relevant if someone use sqlite as the default database backend for multiuser applications with stored procedures.
That's the problem here: Systems built on sharing the database over a networked filesystem, where one user can not just modify all the data, but can also execute code on all users machines.
I have memories of supporting a Netware network with a custom Foxpro app used by a bunch of telemarketers in the mid 90's.
When there was application error the source code would pop up in dialog maybe a some sort of debugger and the end users would just type a bunch of crap in trying to get out of it and hit enter and save the changes and corrupt the app for everyone and it would have to be restored from backup.
Pretty sure it was Foxpro or maybe dbase, definitely wasn't MS Access as it was still a dos based client.
Very different idea about app security back then, was really nice to developed the db, GUI front end and printable reports all in single runtime though.
The largest VFP project I worked on used MS SQL Server.
Foxpro's local DB handling was amazing at pulling down tables, doing complex bulk operations, and pushing the changes. Data transfer was fast, coding ergonomics were great. On top of the extremely low-cost UI creation, it was a no-brainer.
But expectations were changing, everybody wanted to run it everywhere. Citrix bought some time, but the writing was on the wall.
If it isn't client / server architecture there's no privilege separation using SQLite either. The storage format isn't the concern. Rather, the concern is it all runs in the same OS security context.
Exactly, or an access database. This is to enable end users who live in a fully locked down environment (enterprise setup) and can't install anything to use database like features without having to wait 6 months for IT to lift a finger.
But if it starts being a system of records / authoritative system, there needs to be a plan to decommission it.
Maybe there's a way to run them more securely with a wrapper.
It does make sense to try and move to a sql db of some type, and my immediate thought is if something like Postgres, with a plugin or extension or two couldn't simulate enough of Foxpro.
That, or rewriting large parts of the DB engine seem readily much more possible now with LLM driven development.
> Here’s my problem with reviving FoxPro in any form
And then it moves to the orthogonal problem:
> SQL DB
(that in fact means: An app made for end users that are not trusted by default but really are somehow that is a improper implementation of the relational model and more improper developer platform, more like wordpress, and because is mostly deployed "networked" suddenly need to worry about remote access, that is totally not the main point of old Fox/dbase apps!)
And the funny things: SQL injection is not a problem with a Fox app (use of a stringy api is a MAJOR issue that lack of a permission model)
---
As one that have long experience with FoxPro and try to revive the style, lets go to the core of the problem:
Imagine you say to a C developer:
"You can't use `fopen` and other filesystem APIs, because well you have access to to the whole filesystem"
Or even better, the user!:
"You should not own your own filesystem!"
The DB is like the filesystem, but not that dumb!
The permissions model is orthogonal. Maybe you (normal) filesystem is running on a networked deployment with access by spies with and other personal that should have top-notch security.
Or is just a embedded device.
WHAT DECIDE THE SECURITY MODEl?
The kind of storage?
Nope!
Is the deployment and use case.
Similarly, what decide the security of a database?, the fact is a "database"?
No!, that is ridiculous. If you need to layer some kind of access control or whatever, is outside of the kind of storage you choses.
In fact, see how Wonderfully could be all if the "filesystem" where an actual database and you can run relational queries on top: Millions of "cli utilities" suddenly are unnecessary, the user (and developers!) have more freedom and control, and your big corp with byzantine rules will be even more happy.
----
P.D: I'm very well aware of the limitations of Fox, is ancient software! but the style of programming? Is like have a taste of start trek
P.D.2: And note that the vector attack described here is a fault of the dumb filesystem, actually!
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.)
Perfect. I'm looking for a program that executes everything it reads. You've tracked a 20-year-old security bug for FoxPro? That's gnarly. What if, instead of reviving FoxPro, we summon a new type of DOS with no security model to begin with? FoxPro was always better that way.
Hear me out. So, you have your regular computer on your desk, right? I call that the REAL SECURITY computer for REAL WORK: You know, your typical choice of Windows 11, Apple, or Linux. The biggest names in security. The names we trust. Real work. Real computers. Real security.
Next to it sits FoxPro, running new DOS on a separate computer with no security model at all.
Here's the ergonomics. You press your hands against your desk and push your office chair off like a boat, gliding away from the SECURE COMPUTER in the REAL WORLD toward FoxPro. FoxPro reads everything and executes with religious zeal.
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).
When networked PCs and rapid application development platforms became popular there was a "Cambrian explosion" of custom electronic health record and practice management applications built by doctor hackers who knew exactly what they wanted, and had just barely enough technical skill to sort of make it partially work. Those have gradually died off because commercial products kept improving, and the cost of complying with security and interoperability requirements kept escalating. But I predict that the cycle will now repeat because the combination of AI coding tools plus headless EHR platforms (built in security, storage, and APIs) has made it easier to build a custom EHR that actually works.
Yes, I am seeing exactly this at my own workplace. Two things have happened close together: low code and LLMs. I don't personally like using low code solutions (such as PowerBI and Power Automate), but for many knowledge workers this is all they have. Now you can just ask your favorite LLM how to do stuff and it can help you. It's not exactly vibe coding because these people really understand what they have and what they want, they just don't know the syntax to get there.
Low code solution have a fairly steep learning curve, and when someone got into it in anger, the complex electrical diagrams that result are even more impenetrable than spaghetti code.
In a large enterprise environment I have seen business users getting burned by vibe coding already, as they often don't even read the comments and warnings that the LLM gives them. But I think it is inevitable and should enable software to automate the millions of manual processes that are too bespoke to pay an IT team to automate.
For a solo entrepreneur, it should enable to get so much done before having to hire the first employee. Hence less risk to go bust, easier to take risks, pure value added.
DBase/Fox Pro were born when local networks weren't common, it excelled as a single-user batteries-included IDE. Now that you mention this, I understand why it couldn't work these days as it is.
I also think it won't be that hard to make it multiuser, that's a long-ago solved problem these days.
It wasn’t that hard to make it multiuser back on the day, either. But as OP discovered, FoxPro also made it very easy to write shit multiuser code. Pessimistic/optimistic locking, etc.? It was in there, but you had to use it.
One fear I saw manifest in a job was before AI, and an associate was doing a screen for a request in dot net and it let the user read the record, edit the record and write the record. Last person to write the record won of course.
At this tier of small time company IT, I am hoping that AI will actually improve the quality of code, because people who write racey nolock code that occasionally "drops a few records" are probably hopefully not posting their code to forums or alternatively getting roasted to pieces if they do so its my hope they are only represented in training data as "what not to do."
Just antidotal but I don't know how many times I've had to help developers fix their vibe coded code to account for concurrency problems. LLMs don't seem to be very good at picking up on this today unless you call it out.
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.
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.
We wrote and used a lot of dbf files on a server in a major bank and no problems.
Albeit using clipper.
But we had no issues as locking did exist.
The clipper management cam over to the UK to see us and other UK customers. They were shocked to find their small project was doing life critical things for medics and putting thousand of millions of pounds of trades through their code.
Probably plug and play except the indicies are a different file type.
Speed I can't rememeber (it was 40 years ago) then again the speed of a dbase etc program is limited by disk access
It was an internal system so no real comparison.
I do not think we converted much from dBase to Clipper, I assume the first programs did before I joined but by that time we had in house libraries etc.
Oh boy, do I have some stories. I've worked with many companies that actually still do this today. You'd be amazed at what someone can do with VFP and Citrix - or maybe horrified.
The only Citrix Metaframe (and later Windows Terminal Server) machines I ever deployed in Real Life were because of shared-file database-based applications.
> it sucks when one of these systems outgrows the capabilities of the underlying platform.
It did, but does it still with AI? Back in the 90's it was crazy painful. I'm not in the same situations as I was back then, but I'm optimistic about the future being better because we have better tools today than we did back then.
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.
> 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?
My unsubstantiated theory is that it’s due to large amounts of human slop in the training data: marketing blurbs, slide decks, motivational writing, copy designed to sell ad impressions, posts on LinkedIn, and so on. This style is what you get when you pile all that slop together and stir vigorously, i.e. when you train a model on it.
Sentences like the one you quoted seem to be deliberately attempting to create a hook that’s supposed to lure the reader into reading further to find out what, in this case, “that decides”. But when that deliberately manipulative style is jammed into every other sentence, the result is terrible.
Perhaps this is a good use case for AI? I'm sure it's trivial to write an AI system that reads AI text and replaces AI-generated text with AI-generated, non-AI-looking text.
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.
My daughter loves foxes. When I made a desktop shortcut to allow her to easily hibernate her school laptop I knew right where to go to get an icon she'd like.
I love the detail in these things... icons today don't take advantage of the incredibly high resolution of modern screens, they're just wishy washy corporate logos
> "The IDE, on Visual FoxPro's own sample projects. Every picture is a real session." starting to have involuntary revulsive twitches from Claude prose
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.
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.
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.
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)
Access is so good. I can't believe there's no universal equivalent for Linux and Mac. There are dozens of times when I've used a spreadsheet when a file-based database would have been better.
The father of a girl I dated in college (circa 2000s) built an entire student tracking system using FileMaker to use at the High School he was the Principal of.
We didn't date for long, but I'd be curious to know how long that system ran.
I looked at FileMaker a few years ago because it would’ve been a nice setup for a semi-technical acquaintance. And then I saw its pricing, and we went in a different direction.
Someone will no doubt correct my hazy memory, but I wonder how much to blame was the fact that default QT apps were so ugly around the time that was the height of RAD, and QT was the only(?) well-supported cross-platform cross-DE gui framework at that time.
On windows you could RAD your way to a good looking windows application that looked and behaved like everything else. On linux, default behaviour was either ugly, or not very compatible, or heavily customised anyway, and that didn't change until much later with improvements to GTK.
For RAD, Delphi was filling a pretty big niche in its day, and it's still used in some companies local to me. I remember being told during an interview that it performs really well and it's kept up well enough with the changing times. I knew someone from University about 10 years ago that got her first Software job writing Delphi!
I think Microsoft coming out with XAML/WPF created too much complexity for most of the developers that were working with WinForms. Although the code had better separation from the interface, it also took quite a bit more effort to get an application up and running quickly. They took the "R" out of RAD, and then kind of put both WinForms and WPF on life support, while continuing to tout cross-platform on .NET Core without a first-party GUI platform. Now it just looks like Azure was always going to be the solution, to tie users into a platform they don't fully control.
I ran into all of this with the first few years of my career. Even after years, MAUI has struggled to gain traction and Avalonia has grown and is far more the de-facto choice for .NET cross-platform GUI. Both work collegues and myself have ran into XAML/WPF Styling horrors where it's all one giant aggregation/inheritance nightmare generated by Blend (and done by someone that didn't quite know what they were doing)
It always seemed to me that a lack of gentle “WPF for Windows Forms developers” documentation was more of a problem here than WPF itself, which no more enforces the separation of presentation and execution than Windows Forms does, it just gives you more and higher-level options for how code interacts with the layout.
> I'm shocked in general at the lack of open source Rapid Application Development software.
They exist:
- In particular in the 90s and 00s, Tcl/Tk was really magic for creating user interfaces for small applications under GNU/Linux.
- Lazarus attempts to be an open-source analogue to Delphi
- LibreOffice Base attempts to fill the same niche as Microsoft Access
- Historically, in the time of Gtk+ 1.x and 2.x Glade [1] was an editor for clicking together user interfaces. Well, development ceased, and under GNU/Linux there is no attitude of retaining backwards compatibility with applications/libraries that are not maintained anymore (but which might be business-critical).
- ...
But of course Rapid Application Development is much more popular in the business world which is (at least in many European countries) a rather Microsoft-centric environment. Additionally, the typical developer that uses Rapid Application Development is often a subject-matter expert in some department who also knows a little bit about programming (i.e. is not in deep love with programming), and not a programming expert who also knows about some other specialized topics that are important for the business.
On the other hand, the open source environment typically rather attracts people who really like programming.
If your into C++, there is U++ (Ultimate++), which is a fully featured RAD ide equivalent to Lazarus with the fastest compiler I've seen. It compiles to Win/Mac/Linux/BSD.
Nerds have vested interests (exposure/influence/status based on exclusivity of skill) to oppose letting ”the wrong people” create software, versus a company like Microsoft is the other way around because they get paid and get to further-entrench their platforms (but I repeat myself).
And/or too many people have internalized a feeling of “I am Very Smart because I know better than to ever try anything unique”, as exemplified by that awful xkcd ‘Standards’ learned-helplessness comic somebody will always rush to post in a discussion of any New Thing, and thus would never even dream of creating RAD tools whose entire premise is the creation of bespoke software.
In the mid-2000's, I built a lot of applications replacing Access. I always met with the actual users of the system, and made sure they understood that once I took over development, they weren't going to be able to build out their own forms anymore. A few clients were turned away, but most could live with paying for myself to make any future edits, so that they could concentrate on the business objective rather than coding in Access. I never really had the same success with replacing Excel, except for a few systems where it needed to be true multi-user.
I am not going to claim it is any good, it suffers from the same problem most rapid application toolkits have, the easy stuff is easier, the hard stuff is harder. I was playing around at one point to see if it was worth using as a graphical interface to a postgres database. And... it worked. But in the end I preferred writing web applications. As much as I hate web dev it was better than the RAD jank.
I've looked into these before and they're often a monthly/annual SaaS that are either by a one-person company, or worse, something like AirTable that gets crazy price hikes out of nowhere (or shut down) that's a disaster for a small company. Place I worked already had Microsoft Office paid for so why move away from Access.
If it works for you then there is no need to switch. But Access is a desktop app, and in 2026 it is pretty unusual to use a desktop app for business applications. Also, Microsoft is no longer developing Access.
In 2026, Microsoft Access is still fully supported and bundled into Microsoft 365 Enterprise subscriptions. Back in 2014, I'd said to my employer that it's not going anywhere for at least a decade (and that they can fully ignore a report they'd received from the NDPB that oversaw their work that suggested Access might be at risk of disappearing)
>In 2026, Microsoft Access is still fully supported and bundled into Microsoft 365 Enterprise subscriptions.
Having a subscription is only a small part of the total cost. Access works best when combined with a bunch of VBS/macro scripts, which IT departments globally are trying very hard to stamp out completely. Access also needs its own set of permissions and manager of permissions since it can't inherit permissions from anywhere of the other usual Microslop security stores - at least, not without having its own developer/maintainer/champion on tap.
Not to mention the agreed wisdom that while Access is fantastic for rapid-prototyping applications/warehouses/ETL processes, any "permanent" DB/DBMS/solution worth doing in Access is worth doing in a 'proper' database with a proper front-end.
All true and yeah, I did discuss with my employer at the time about how they needed to think long term about migrating to SQL Server or MySQL/PostgreSQL with a web front-end. However, the giant IT contractor they were stuck with would only allow SQL Server and charge a fortune, and they didn't have the time/money/know-how to go anywhere with that. They were stuck with Access!
> Access works best when combined with a bunch of VBS/macro scripts...
You're thinking of Visual Basic for Applications (VBA), which is interpreted inside of Access. The standalone Visual Basic Scripting (VBScript) is a completely different thing, and eliminating VBScript doesn't have any ramifications for Access.
As long as it has a significant number of users Microsoft will keep shipping it. But it is not getting significant new investment. If you are building a new application you're better off using Power Apps, Dataverse, SharePoint, Power Automate, etc.
Technically, MS Power Apps is the successor to MS Access. Power Apps is a web application so that solves the cross platform problem.
Having played with it, it’s not as turn key as either MS Access or something like Airtable. It can be overly complicated and it’s infected with the paradox of choice.
Access is a whole package with form designers, widgets, scripting, etc. so that you can build an entire distributable app from it. SQLite's a brilliant little DB but it only covers a tiny portion of what Access does.
I kinda loathe access for any number of reasons, but appreciate the dev tools it put into the hands of non-developers. A great many people who'd be passive users on most systems were able to build apps to meet their business and requirements, and although Access was janky as hell, that's very, very cool. I think it's most spiritually similar to HyperCard on Mac: you wouldn't want to write a whole large app in it, and if you're an experienced developer there are any number of tools you'd rather write programs with. But if you weren't a traditional developer (e.g. an office worker or a student or a home computer enthusiast, etc.) it gave you a pleasant hand-holding process for making your ideas come to life. I respect that.
Gambas was neat. I think we also looked at Kivy at the time, and I think there were a couple of other Python RAD systems that aimed to be similar to VFP in spirit, although not even slightly compatible.
Pretty sure all the upvotes came from folks nostalgic about FoxPro development days. I don't think anyone is actually upvoting the quality of the seemingly fully AI written website, documentation, and application.
My godfather that helped me get into computers used to make a decent living doing foxpro databases for companies in the 90s. We lost touch years ago, I always wondered if he stuck with it.
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.
I have been working on a VB6 recreation starting with the IDE. Eventually I want to build the compiler and runtime, but for now being able to open existing projects, load all the images and do all the syntax highlighting is a good first step.
I know TwinBasic exists but its closed source and I want to take things further than VB6 ever did. I always felt like VB7 could have been something amazing if it kept going outside of .NET but they let it go and basically killed a really rich language by breaking all sane compatibility.
Maybe worth me putting support for this project, and I too intend to license my efforts under the MIT license. ;)
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 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.
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.
Without fail, these vibe coded project websites all make themselves look way more ambitious and established than they actually are. A software project could be hours old and it will have a website that, just a handful of years ago, only projects that had been around for a while and with a revenue model would have had. To me, it comes off as so overly persuasive that the only thing I can think nowadays is "what sort of half-baked junk are they trying to sell me?" Today, a primitive website or a mere handwritten README.md is, ironically, a more reliable signal of whether an application is worth considering. At least to me, anyway.
Unlike most other people here, I wouldn't really say I've developed a radar for "the vibecoded webpage design"; I thankfully don't dabble as much with FE nowadays so if you told me this is default Bootstrap 4 or something, I'd have believed you. But as I scrolled through the claims, my AI-generated text radar pinged hard and I was caught in a moment of dissonance between the sleek design and the AI-cadenced copy.
Suddenly, I would've had more confidence if this was a black default font text on a white webpage, served from a .edu domain.
> The nightly is rebuilt from every push to main and published as a pre-release on GitHub. Unsigned, so the first launch asks you to confirm.
But with only two commits within the hour this really reads more like a concept of a release plan than an actual regimented/automated release process.
My problem with vibecoded projects was never whether if it was going to work but whether if the failure modes are known. And you can only know the failure modes if you check your work. Hence why, I realized that a history of alpha and beta releases for an opensource project is a signal of quality.
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
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.
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.
I was an undergraduate in the late 1980s/early 1990s and I worked part time in the university library working on databases and interfaces first in dBase III then Foxbase (the predecessor to Foxpro; basically an extended dBase III clone) then DOS FoxPro. I rather liked them, but this was long before I had ever seen SQL or anything like that. The weird thing was that my boss (besides being the library's IT guy) was a taekwondo instructor! What is it about FoxPro and that?
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.
DBF is a straightforward and widely implemented file format, so I assume LLMs would have little trouble extracting raw data. No idea about programmatic access, but I assume the answer is yes.
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.
Yup, same story for me. Father-in-law owned a consulting business on the side. (CS Professor was his day job) His apps were CA Clipper, DB3, VB4-6, FoxPro, Turbo Pascal, Delphi. I worked for him for years in college. Doctors offices, dentist offices and an oil company. What a time to be in the programming gig! I migrated Novell servers and moved customers from Btrieve to PervasiveSQL. We got into open source pretty early (1998 - which one might argue wasn't THAT early). Some of our "next-gen" stuff used Perl:DBI, Python + MySQL, PHP3. I got such a crash course in cool tech.
The one thing I learned early on. MS-JET is NOT something you want to share from a server! Dbase dbf on the other hand, seemed to work fine.
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.
Vernor Vinge's A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. <https://web.archive.org/web/20231114211656/http://www.gareth...>
(Heck, recently I migrated a VM to its third hypervisor. It began as a physical machine a quarter century ago.)
I too maintain a small fleet of virtualized copies of the silent machines which now still sit on the shelf, unpowered, nevertheless .. there if they are needed.
Vernor Vinge’s works have indeed had a huge impact on the way we think about things, and his immense insight is still extraordinary with every read.
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.
Didn't expect an AppImage and a .deb in the downloads. How much of an app survives on Linux, though? Plenty of VFP code drives Excel through CREATEOBJECT, and the .fll bridge is a 32-bit Windows process. What happens to those calls there?
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.
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
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.
what a great idea, and has the potential to pull $10m in a year or so. engineers everywhere should be pursuing these projects. So many businesses are running on "legacy" platforms. Glance over the costco customer service desk , they're still using some cobol dos inventory system.
Clone it with cheaper tools, and win the next $100m / yr contract from costco at half the price. There are 100k opportunities out there right now.
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.
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 :)
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.
I believe it would be helpful for those who would want to continue development, contribute to the project.
Pro-AI people now argue that the code is ephemeral nowadays, we should not look at it like we don't look at generated assembly (most of the devs). So in this regard, sharing only the "assembly" doesn't make sense, it's like sharing only the binaries and calling that open source (before LLM days).
I expect a real big-gish project would have possibly hundreds or thousands of such sessions. And personally I've never needed to dig back an old session for reference, only when I'm still actively working on the topic. They don't have a particular structure, whereas the actual code has a lot of structure.
But maybe it would be useful to have the related chats in the actual git commits that introduce the features. This way, if you (or the agent) `git bisect`s an issue, the same context that was used to construct the feature could be used for making the fix as well. I have never tried this approach, but it sounds like it could be useful.
It's slightly annoying that most (all?) harnesses store the chat logs in a db outside the project, and additionally e.g. OpenCode doesn't give the agent a direct way to access the complete current session context. So implementing this currently would be a bit hacky (find session by time? generate random string in context and find the session?).
It was boxed software that, when going to a computer/office store as a child in the mid-1990s, you wanted your parents to buy because it had a fox on the cover and in the name without actually knowing what it did.
Besides being a DB with forms, reports, etc as already mentioned by others - its significance was huge as it was the peak of an era where small/single developers could deliver business solutions by knowing a single tool, and people with domain knowledge could write their own solutions.
Since then everything became much more complex - networking, security, GUIs, web development, deployment, etc.
A tool and language to write apps where you could write "Select * from customers" in the command window and get results right there in a browse table, beautifully
Yes, they bought it. But they didn’t buy it and stab it in the heart. They developed it for several years.
A primary bit of tech that came out of the purchase was the core DB engine. They reworked this into what became the Jet engine. The Jet engine was the core of Access.
Access was in many ways a next generation of FoxPro. They both went after the same niche of desktop and file server DB applications. But FoxPro carried the legacy of its dBase roots, FoxBase was basically “better dBase”, but had to appeal to and be familiar to dBase developers.
Access had no heritage like that to hold it back, and was a better citizen in the VB/Office/OLE/COM world. It was also more SQL first even though it kept things like DBF files as first class citizens.
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).
- multisig approach: you can require multiple signers to sign a release for it to be accepted by downloaders. Protects against account compromise. Sigstore relies on OIDC, but this makes it often reliant on megacorps (and harder to self host, see next point)
- very easy to self host. You can deploy it internally without any problem, eg in an airgapped environment where you want to distribute signed artifact. This is impossible with Sigstore.
- accountless: the key is the identity. The multisig approach diminishes the problems that long-lived keys might bring. And you don't rely on an external OIDC provider to be able to sign.
- Air-gapped signers: it is possible to have air-gapped signers, as signing does not rely on an online service to verify an identity.
- easy for downloader: the use only has to provide the download url, and this is sufficient to authenticate the download.
- easy to audit: the backend data is stored in a git, that will be mirrored in different places, and anyone can mirror it for themselves.
You might agree or not with these choices, but there are enough differences to say that it doesn't reinvent the wheel, it's providing another approach which I think has its advantages.
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!
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?
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.
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
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):
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!
Probably. The website does look too good though, none of the design cruft ("eyebrows") that LLMs like. But the last design I let it do was from opus 4.7 or gpt 5.3.
Obviously they used AI at some point in the project, the question to you is what is your definition of vibe coding and how does it discredit the effort they did put into it?
One benchmark would be: would someone with a legacy FoxPro LOB app be entrusting their data to this? Or is it just a nice "wow, that's a cool project"?
The website is obviously and gratingly LLM-voiced. I don't know how people aren't tired of paragraphs like this yet:
"Visual FoxPro is a 32-bit program, and that decides more than it appears to. It is why a table stops at two gigabytes, why a memo file stops at two gigabytes, and why a big report runs out of memory on a machine with plenty to spare. The limits are signed 32-bit numbers buried in the file handling, not a licensing decision anybody made."
and
"The editor checks what you type through that very compiler, so what it underlines and what the runtime refuses cannot drift apart."
Right, yes, this sort of style certainly can be produced by writers, especially ones who are working in a particular corporate universe. That's where LLMs got it from! It just sucks that everyone "writes" like that now. Every new one-person project or company is incongruously spouting corporatese. Don't we get enough of that already? Flattening everything into American corpo-speak sucks.
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.
>, 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.
A person's perspective on the older dev tools being "superior" to today's newer tools depends on the things they want to build.
I had jobs working on Foxbase/FoxPro for DOS and migrated those apps to FoxPro for Windows, and Visual Basic 3.0 to 6.0 ... and I don't look back at those with the same positive nostalgia.
Classic VB was "simple" but every project at each company had a different hodge podge of 3rd-party VBX/OCX add-on controls to do anything non-trivial. E.g. 3rd-party calendar date picker, report writer, etc. VB didn't have a decent datagrid so everybody bought a 3rd-party one. In contrast, C# WinForms standard controls included a usable datagrid with data binding out of the box.
In a FoxPro for Windows project I was working on, we needed to open .zip files. FoxPro didn't have that functionality so the company paid an extra $300 for the FoxPro Library Construction Kit[1] and I hand-coded a .zip file parser in C Language to be called by FoxPro code. Instead of FoxPro dev work being simple, it's complex! Today's Python or C# can trivially open .zip files with builtin modules and functions so devs don't waste time on writing low-level C code or use 3rd-party libs.
With old 1990s tools, you can't do "simple" tasks such as getting a UTC timestamp, use a regex expression, or retrieve a web page with an http call, etc without calling Win32 API functions or 3rd-party tools.
If one wants to do things beyond the limitations of classic VB/FoxPro, the newer dev tools like Python/C# etc absolutely do make things easier and faster.
[1] https://www.scribd.com/document/384159949/Ms-Foxpro-Develope...
This is only tangentially related but I often wonder about the nature of software and whether we made a mistake "standardizing" as much as we have.
I say this not because you're wrong - I'm sure that using built-in modules for .zip parsing is faster and easier! - but rather because I don't know whether or not it's worth knowing how to do that. In the AI days right now there's argument being had about whether learning any coding at all is valuable. My gut says it is, but I've also spent years learning before AI, so maybe it's a sunk cost fallacy.
Regardless, my feeling is that we haven't found the balance between what's worth making every programmer learn/implement themselves, and what's worth abstracting away. Maybe implementing a .zip parser gives you some kind of secret wisdom that makes your future work better?
I'd hardly consider it secret, or wisdom, but I can think of many problems involving ZIP files I've solved in the past that it wouldn't even have occured to me to pose if I hadn't understood the broad structure of ZIP files as a series of metadata/data pairs followed by an index containing a mostly redundant copy of the metadata.
In other words, solving the right problems, however inefficiently, will always be more useful than solving the wrong problems efficiently.
Oh the VBX > OCX transition nightmare...
At the time I worked for an organization which pretty much had an unlimited budget for development and had therefore purchased just about every VBX bundle. They also had a solution with about 90+ complex forms - and no standards, so each developer of each form would pick whichever VBX control that "pleased their eyes". Which was "fine", until about 50% of those VBX control vendors simply did not offer an OCX upgrade in a timely manner - or in many cases simply folded/stopped entirely...
(The next nightmare was transitioning to what was supposed to be a more loosely-coupled COM type architecture, where each form could be dynamically loaded - except, referenced dependency tree and "breaking-binary-compatibility" during weekly "clean builds" ended-up taking sooooo much time... Thanks to a tool from a MSFT employee via their consulting service called "VBBuilder" (think of essentially "make") finally helped reduce that manual effort from a full day to just minutes...)
I don't recall that I ever did this with a FoxPro app. I used to make part of my money porting or cloning bespoke small business apps to OpenOffice Basic or OpenOffice with its Python integration. Visual Basic, QuickBasic, MS Basic PDS, TurboBasic, MS Access, and Turbo Pascal apps I'd replace with the integrated languages of the office suite.
Some of those originals used DBase III or DBase IV libraries. Some used bdb libraries. An awful lot used fixed-width fields designed into the application itself. Many of them I wouldn't have the source for, so I'd have to reverse engineer the data file format a little and then write a proper schema for a real database.
Sometimes the hardest part was getting the forms to look acceptable to employees at my client who were used to a curses style interface.
> Delphi
Delphi is alive. https://www.embarcadero.com/products/delphi
Often FreePascal with Lazarus is a suitable alternative, and it's also very much alive.
A big software for simulating the economic balance sheets of life insurance companies moved many years ago from using FoxPro under the hood to CSV files and sold it as a huge improvement. I don't think anybody was convinced by that, but vendor lock-in makes companies accept such regressions.
I was on a project trying to migrate off Oracle and they wanted to just dump all historic data to CSVs.
I pointed out they'd lose a lot of the integrity and audit features built into a database.
I get wanting to be free from Oracle but go to another database.
I wonder how that happened.
Maybe someone proposed Postgres and they said well who is going to support it. And then they'd have to pay some company to show they have postgres support anyway.
CSV has no support.
I once worked on maintaining an accounting package that exported to csv. At one point there was a bug where if the notation for a transaction included a single unmatched quote, the rest of the exported data silently disappeared.
The depressing part wasn’t finding this bug (in a very mature codebase), it was painstakingly explaining what the problem was and how to fix it.
> Delphi, Visual FoxPro, Visual Basic, Flash
All these tools are nice for a single developer. But they fail to scale for teams where you want a distributed version system, automated tests and CI/CD pipelines. Also you want to reuse code via package management systems. And a single code base for several target systems (cross compilation , electron) is also nice. I believe the mentioned tools offer none of this.
> But they fail to scale for teams where you want a distributed version system, automated tests and CI/CD pipelines.
I don't think this is true? Certainly you could have done those things with Delphi but it pre-dated DVCS and CI/CD being common concerns.
> Also you want to reuse code via package management systems.
Again, these tools pre-dated package management systems being in common use because they pre-date internet access at any sort of bandwidth being a reliable assumption. No reason they couldn't have one. Perl did at the time, which I mainly put down to it being in common use where internet access was a reliable assumption, but very little else did.
> And a single code base for several target systems (cross compilation , electron) is also nice
You can absolutely do this with Lazarus, which picked up where Delphi left off. Flash also counts here.
At least FoxPro stores code in binary files, but I’ve seen scripts to convert them back and forth to a text representation that can be checked in.
Think Flash (eventually) had most of these. That said, not all software development needs to happen at the same scale and not all software authoring environments benefit from the same tradeoffs vis-a-vis complexity, collaboration, accesibility etc. the success of Flash as a platform for independent game devs shows that different markets are better served by different tradeoffs.
> Also you want to reuse code via package management systems.
I thought everyone was on monorepos to "solve" that.
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
> And there are industry that is extremely conservative in anything software
Honestly, that's at least 90% of non-tech industry, and there's a good living to be made as a consultant that can support legacy software.
> Niche but no small business, commodity with over $400M USD annual revenue, the industry together that is easily $2B+.
This feels so small in 2026.
It feels small to some people in 2026, depending on the business type and the field. Most businesses are small businesses, though. It actually approaches 100%. This is under the SBA's definition as of not long ago. There are limits on earnings, number of employees, or both for what can even be considered a "small business" that vary by industry. They are as low as $9 million revenue or 100 employees, although some industries have much higher ceilings. https://legacy.sba.gov/sites/default/files/2023-06/Table%20o...
The average annual revenue of a small business in the US in 2026 is around $1.2 million. The average headcount is about 11 people. About 46% of employees in the US are employed by small businesses. In 2024, about 64% of new jobs were created by small businesses. About 61% of new jobs from 1991 to 2025 were created in small businesses.
https://entrepreneurshq.com/small-business-statistics/
https://www.forafinancial.com/blog/small-business/average-sm...
https://www.venasolutions.com/blog/small-business-revenue-st...
As a small business owner, aware of all of this.
That said:
> It feels small to some people in 2026, depending on the business type and the field
$2Bn was stated as the size of an entire industry, which is weird when you work at companies that do more than that a fiscal quarter.
Well, commodities are commodities, and it was said it was a niche market. The company itself seems pretty big to me, relatively. $400m in a market of about $2b means they fill a pretty substantial part of the available market.
I haven't used Delphi since I was a child.
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.
One of the Ohio Secretary of State's "certified" (wrong terminology, but you get the idea) voter registration databases used by various county Boards of Elections is written in VFP. The software maintains the list of voters, their addresses, and scans of signatures.
Recently it had TOTP 'MFA' added to comply with a Secretary of State mandate.
Anyone who uses the software can just open the database files directly. They're just DBF files in a shared folder on a file server. All the users have to have read/write access to the files or the application won't work.
I hang my head.
Sounds like it works as designed.
seen this exact pattern in small business FoxPro setups too, DBFs on a share are one dropped SMB connection away from a corrupted index. if you're stuck maintaining something like this the least bad move is nightly copies of the whole folder to a second box, and actually opening that copy in the app now and then instead of just checking that the file sizes match.
This is an _excellent_ example of what anyone who has been professionally responsible for backups means when they say "it's not a backup until you've restored from it, booted into it, opened the app, and accessed the data"
There's still so much software out there that is an absolute lynchpin to a business that will never have the kind of durability/compatability many take for granted. The only thing that has changed in the past 2 decades is the operating system running the VM. In 2026 they are still yelling across the office or exchanging phone calls when one has finished and signed out so that the other can sign in and pull the updates.
It often isn't taken seriously or is written off because it's a "small business", but those 2-8 people run a book of business that clears this comment thread's lifetime earnings annually.
there is no permissions scheme
If you already have full access by design, then there's no "huge security hole" either.
This is entirely how FP is supposed to work. Don't like that, don't use it.
It ships database files over the network and does that blazingly fast.
Exactly. It's not a security hole. It's just the architecture of the program.
It seems like many people have a hard time understanding this, including developers.
Any attempt to add any kind of permissions, security, etc, without addressing the nature of the architecture (that the database engine runs in the same address space / security context as the UI) misses the point.
Further along those lines, it was a different world when the code was created.
Trust was a thing back then. Spam was something that came out of a tin and was made of dead animal. And passwords were limited to eight ASCII characters.
And as such, bolting security onto something that was designed inherently to be security agnostic is going to be a recipe for failure.
It had absolutely nothing to do with trust. People still worried about the security of their databases. Businesses understood perfectly well that their electronic records were just as sensitive as their paper ones. But the server closet had a lock on the door, and no wire connecting it to a global network of mostly scammers. It was just as secure as the paper records.
Trust was a thing back then.
No, it wasn't. The reason I even raised this bug to begin with was not because of some nefarious $BAD_COUNTRY hacker getting yer dataz from far away, it's because you have to worry about your own users first. I'd guess that any consultant doing the kind of work FoxPro excelled at (LOB apps) has found some clever boy or girl who discovered they can poke at DBF files directly. Long before internet connectivity was common, one still had to worry about your own coworkers futzing things up.
You’re saying it’s not a 2 tier client/server app, it’s a one tier app with no intermediate API to define or enforce permissions. Fine.
But the filesystem access to read/write the db files creates a path to bypass half of that application.
Does the application checksum the db file and have any resistance to filesystem tampering? That'd be trivial to beat, I’m sure, but it’d be something.
Well, on a different note, if you have a scripted language application, you typically can edit files and bypass whatever you want on the application. In fact, I'd bet most modern software isn't signed; and even if it is, sometimes the libraries that get compiled in into that signed binary... aren't.
I can change the behaviour of many/most applications by just having read/write access to files; Can you give me examples of mainstream applications that are resistant to filesystem tampering when eg.you have install access? Maybe I'm missing something.
> But the filesystem access to read/write the db files creates a path to bypass half of that application.
Is there any local/native application for which this is not true?
With a permissions system that’s meant to enforce security? I hope not.
I’m not a FoxPro user and so maybe these are single-user/single-host installs, where the user can only destroy their own data, and permissions are a pretend feature. In which case, carry on.
> With a permissions system that’s meant to enforce security? I hope not.
There's different needs for a permissions system.
You're thinking of it as "lock to the main entrance of a maximum security prison". Think of it more as a lock on a bedroom door: it's not there to withstand a SWAT assault, it's there to keep people from accidentally walking in.
All local applications (which were all applications in the era we are talking about) with permissions were sold to companies on the understanding that there was no real security.
Hell, even the networked products at the time had no real security :-/
Can't you just use filesystem permissions? Like, FoxPro under its own user and it's database owned and accessible by FoxPro user only?
Sure. The user would need to logon as the FoxPro user to use the application. At that point, having the FoxPro user credentials, the user can manipulate the FoxPro data files directly without using the application.
The rub here is that FoxPro is an in-process database engine and accesses its data files with the security context of the user running the application. It doesn't have separation between the database engine and the UI like a client/server database would. Think of it like SQLite or BerkeleyDB.
Architecturally users who use the application need full read/write access to all the data files for FoxPro to work.
Well, I had to call it something. File system DBs were a problem long before FoxPro’s DBCs, yes. Yes, it’s an architectural decision. Sharp cookies would just modify the files directly. But that would just trash data (or bump my hourly rate in the HR DB). Most of the time, “full access to data” doesn’t necessarily mean “run arbitrary code”. In this case, it does, which I don’t think folks expect, hence “hole”.
There's a category in the OWASP Top 6, called: Insecure Design.
It is top 6 in their vulnerabilities ranking.
This is definitely insecure design.
> Well, I had to call it something.
A significant weakness?
A serious limitation for modern uses / in modern environments?
A massive footgun? :)
Obsolete security model?
Many of the complaints you make apply to SQLite as well?
I don't know if dBASE variants support bind variables. That isolation is really required to avoid the "Bobby Tables" effect.
https://bobby-tables.com/
I'd prefer to see the dBASE language adapted to run on SQLite files, as they are a far more profound standard.
OP never mentioned SQLite. Most SQL products support proper ACLs.
I feel good about you, and that you are a good person, through and through. We don't say that enough here.
The permissions exploits on SQLite and dBASE are identical, sad to say.
You're a good guy. I respect you.
And that would be relevant if someone use sqlite as the default database backend for multiuser applications with stored procedures.
That's the problem here: Systems built on sharing the database over a networked filesystem, where one user can not just modify all the data, but can also execute code on all users machines.
I have memories of supporting a Netware network with a custom Foxpro app used by a bunch of telemarketers in the mid 90's.
When there was application error the source code would pop up in dialog maybe a some sort of debugger and the end users would just type a bunch of crap in trying to get out of it and hit enter and save the changes and corrupt the app for everyone and it would have to be restored from backup.
Pretty sure it was Foxpro or maybe dbase, definitely wasn't MS Access as it was still a dos based client.
Very different idea about app security back then, was really nice to developed the db, GUI front end and printable reports all in single runtime though.
Actually you can use foxpro with mssql and ole, you could than even add row level security for even more security
The largest VFP project I worked on used MS SQL Server.
Foxpro's local DB handling was amazing at pulling down tables, doing complex bulk operations, and pushing the changes. Data transfer was fast, coding ergonomics were great. On top of the extremely low-cost UI creation, it was a no-brainer.
But expectations were changing, everybody wanted to run it everywhere. Citrix bought some time, but the writing was on the wall.
Maybe someone can put the core FoxPro ideas on top of SQLite
If it isn't client / server architecture there's no privilege separation using SQLite either. The storage format isn't the concern. Rather, the concern is it all runs in the same OS security context.
But it is a feature... I mean Excel also runs there...
Exactly, or an access database. This is to enable end users who live in a fully locked down environment (enterprise setup) and can't install anything to use database like features without having to wait 6 months for IT to lift a finger.
But if it starts being a system of records / authoritative system, there needs to be a plan to decommission it.
True. When someone on the internet sends me a vfp file... i just open it in my IE6.0 no cares given.
Could the security hole not be closed up?
Maybe there's a way to run them more securely with a wrapper.
It does make sense to try and move to a sql db of some type, and my immediate thought is if something like Postgres, with a plugin or extension or two couldn't simulate enough of Foxpro.
That, or rewriting large parts of the DB engine seem readily much more possible now with LLM driven development.
> Here’s my problem with reviving FoxPro in any form
And then it moves to the orthogonal problem:
> SQL DB
(that in fact means: An app made for end users that are not trusted by default but really are somehow that is a improper implementation of the relational model and more improper developer platform, more like wordpress, and because is mostly deployed "networked" suddenly need to worry about remote access, that is totally not the main point of old Fox/dbase apps!)
And the funny things: SQL injection is not a problem with a Fox app (use of a stringy api is a MAJOR issue that lack of a permission model)
---
As one that have long experience with FoxPro and try to revive the style, lets go to the core of the problem:
Imagine you say to a C developer:
"You can't use `fopen` and other filesystem APIs, because well you have access to to the whole filesystem"
Or even better, the user!:
"You should not own your own filesystem!"
The DB is like the filesystem, but not that dumb!
The permissions model is orthogonal. Maybe you (normal) filesystem is running on a networked deployment with access by spies with and other personal that should have top-notch security.
Or is just a embedded device.
WHAT DECIDE THE SECURITY MODEl?
The kind of storage?
Nope!
Is the deployment and use case.
Similarly, what decide the security of a database?, the fact is a "database"?
No!, that is ridiculous. If you need to layer some kind of access control or whatever, is outside of the kind of storage you choses.
In fact, see how Wonderfully could be all if the "filesystem" where an actual database and you can run relational queries on top: Millions of "cli utilities" suddenly are unnecessary, the user (and developers!) have more freedom and control, and your big corp with byzantine rules will be even more happy.
----
P.D: I'm very well aware of the limitations of Fox, is ancient software! but the style of programming? Is like have a taste of start trek
P.D.2: And note that the vector attack described here is a fault of the dumb filesystem, actually!
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.)
> FoxPro just executes what it finds in there.
Perfect. I'm looking for a program that executes everything it reads. You've tracked a 20-year-old security bug for FoxPro? That's gnarly. What if, instead of reviving FoxPro, we summon a new type of DOS with no security model to begin with? FoxPro was always better that way.
Hear me out. So, you have your regular computer on your desk, right? I call that the REAL SECURITY computer for REAL WORK: You know, your typical choice of Windows 11, Apple, or Linux. The biggest names in security. The names we trust. Real work. Real computers. Real security.
Next to it sits FoxPro, running new DOS on a separate computer with no security model at all.
Here's the ergonomics. You press your hands against your desk and push your office chair off like a boat, gliding away from the SECURE COMPUTER in the REAL WORLD toward FoxPro. FoxPro reads everything and executes with religious zeal.
- written from my treadmill. edit: fix typos
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).
When networked PCs and rapid application development platforms became popular there was a "Cambrian explosion" of custom electronic health record and practice management applications built by doctor hackers who knew exactly what they wanted, and had just barely enough technical skill to sort of make it partially work. Those have gradually died off because commercial products kept improving, and the cost of complying with security and interoperability requirements kept escalating. But I predict that the cycle will now repeat because the combination of AI coding tools plus headless EHR platforms (built in security, storage, and APIs) has made it easier to build a custom EHR that actually works.
Yes, I am seeing exactly this at my own workplace. Two things have happened close together: low code and LLMs. I don't personally like using low code solutions (such as PowerBI and Power Automate), but for many knowledge workers this is all they have. Now you can just ask your favorite LLM how to do stuff and it can help you. It's not exactly vibe coding because these people really understand what they have and what they want, they just don't know the syntax to get there.
Low code solution have a fairly steep learning curve, and when someone got into it in anger, the complex electrical diagrams that result are even more impenetrable than spaghetti code.
In a large enterprise environment I have seen business users getting burned by vibe coding already, as they often don't even read the comments and warnings that the LLM gives them. But I think it is inevitable and should enable software to automate the millions of manual processes that are too bespoke to pay an IT team to automate.
For a solo entrepreneur, it should enable to get so much done before having to hire the first employee. Hence less risk to go bust, easier to take risks, pure value added.
DBase/Fox Pro were born when local networks weren't common, it excelled as a single-user batteries-included IDE. Now that you mention this, I understand why it couldn't work these days as it is.
I also think it won't be that hard to make it multiuser, that's a long-ago solved problem these days.
It wasn’t that hard to make it multiuser back on the day, either. But as OP discovered, FoxPro also made it very easy to write shit multiuser code. Pessimistic/optimistic locking, etc.? It was in there, but you had to use it.
One fear I saw manifest in a job was before AI, and an associate was doing a screen for a request in dot net and it let the user read the record, edit the record and write the record. Last person to write the record won of course.
At this tier of small time company IT, I am hoping that AI will actually improve the quality of code, because people who write racey nolock code that occasionally "drops a few records" are probably hopefully not posting their code to forums or alternatively getting roasted to pieces if they do so its my hope they are only represented in training data as "what not to do."
Just antidotal but I don't know how many times I've had to help developers fix their vibe coded code to account for concurrency problems. LLMs don't seem to be very good at picking up on this today unless you call it out.
Wow, I’ve had the opposite experience. I’ve needed to talk Claude down from Redis clusters for hobby projects to avoid concurrency edge cases.
Although to your point, it struggles to do anything with SQLite beyond a single user even when its architecturally not a problem
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.
Interesting.
Do you spot any opportunities for new solutions in the real estate space these days?
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.
We wrote and used a lot of dbf files on a server in a major bank and no problems. Albeit using clipper.
But we had no issues as locking did exist.
The clipper management cam over to the UK to see us and other UK customers. They were shocked to find their small project was doing life critical things for medics and putting thousand of millions of pounds of trades through their code.
Three questions:
* How plug-and-play is compiling dBASE code in Clipper? Compiles and runs immediately, needs minor edits, or more work than that?
* How much of a speed improvement does compiling provide?
* How grateful were clients for the speed improvement?
Probably plug and play except the indicies are a different file type.
Speed I can't rememeber (it was 40 years ago) then again the speed of a dbase etc program is limited by disk access
It was an internal system so no real comparison.
I do not think we converted much from dBase to Clipper, I assume the first programs did before I joined but by that time we had in house libraries etc.
Oh boy, do I have some stories. I've worked with many companies that actually still do this today. You'd be amazed at what someone can do with VFP and Citrix - or maybe horrified.
The only Citrix Metaframe (and later Windows Terminal Server) machines I ever deployed in Real Life were because of shared-file database-based applications.
> it sucks when one of these systems outgrows the capabilities of the underlying platform.
It did, but does it still with AI? Back in the 90's it was crazy painful. I'm not in the same situations as I was back then, but I'm optimistic about the future being better because we have better tools today than we did back then.
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
> 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?
Not sure but I'm getting really sad reading anything and seeing this AI speak everywhere.
RLHF. The reviewers that rated the models preferred it.
But were there other outputs that constructed sentences more naturally?
A whole culture suffers due to the awful taste of a few. The more things change…
My unsubstantiated theory is that it’s due to large amounts of human slop in the training data: marketing blurbs, slide decks, motivational writing, copy designed to sell ad impressions, posts on LinkedIn, and so on. This style is what you get when you pile all that slop together and stir vigorously, i.e. when you train a model on it.
Sentences like the one you quoted seem to be deliberately attempting to create a hook that’s supposed to lure the reader into reading further to find out what, in this case, “that decides”. But when that deliberately manipulative style is jammed into every other sentence, the result is terrible.
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.
Perhaps this is a good use case for AI? I'm sure it's trivial to write an AI system that reads AI text and replaces AI-generated text with AI-generated, non-AI-looking text.
AI.
It's incredibly jarring, and subtly nonsensical...
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
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
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.
My daughter loves foxes. When I made a desktop shortcut to allow her to easily hibernate her school laptop I knew right where to go to get an icon she'd like.
moricons.dll holds a very special place in my heart.
https://devblogs.microsoft.com/oldnewthing/20250505-00/?p=11...
https://retrocomputing.stackexchange.com/questions/6705/what...
I love the detail in these things... icons today don't take advantage of the incredibly high resolution of modern screens, they're just wishy washy corporate logos
"The IDE, on Visual FoxPro's own sample projects. Every picture is a real session." starting to have involuntary revulsive twitches from Claude prose
> "The IDE, on Visual FoxPro's own sample projects. Every picture is a real session." starting to have involuntary revulsive twitches from Claude prose
It's beautiful, isn't it?
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.
They are unlikely to still work.
If they do, immediately copy the data over. They tend to crumble and fall apart (and contaminate the drive head, which will need cleaning)
Not to mention that USB drives tend to ignore read only tab and Windows writes the "System Volume Information" folder to the drive.
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.
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.
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.
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)
Access is so good. I can't believe there's no universal equivalent for Linux and Mac. There are dozens of times when I've used a spreadsheet when a file-based database would have been better.
> Access is so good. I can't believe there's no universal equivalent for Linux and Mac.
On the Mac, it's FileMaker,[1] which was released in 1985. Claris is a subsidiary of Apple.
[1]: https://www.claris.com/blog/2026/claris-filemaker-2026-is-no...
The father of a girl I dated in college (circa 2000s) built an entire student tracking system using FileMaker to use at the High School he was the Principal of.
We didn't date for long, but I'd be curious to know how long that system ran.
So glad to see Filemaker is still alive! I had thought it had gone in one of Apple's software culls years ago.
I looked at FileMaker a few years ago because it would’ve been a nice setup for a semi-technical acquaintance. And then I saw its pricing, and we went in a different direction.
I'm shocked in general at the lack of open source Rapid Application Development software.
Someone will no doubt correct my hazy memory, but I wonder how much to blame was the fact that default QT apps were so ugly around the time that was the height of RAD, and QT was the only(?) well-supported cross-platform cross-DE gui framework at that time.
On windows you could RAD your way to a good looking windows application that looked and behaved like everything else. On linux, default behaviour was either ugly, or not very compatible, or heavily customised anyway, and that didn't change until much later with improvements to GTK.
For RAD, Delphi was filling a pretty big niche in its day, and it's still used in some companies local to me. I remember being told during an interview that it performs really well and it's kept up well enough with the changing times. I knew someone from University about 10 years ago that got her first Software job writing Delphi!
I think Microsoft coming out with XAML/WPF created too much complexity for most of the developers that were working with WinForms. Although the code had better separation from the interface, it also took quite a bit more effort to get an application up and running quickly. They took the "R" out of RAD, and then kind of put both WinForms and WPF on life support, while continuing to tout cross-platform on .NET Core without a first-party GUI platform. Now it just looks like Azure was always going to be the solution, to tie users into a platform they don't fully control.
I ran into all of this with the first few years of my career. Even after years, MAUI has struggled to gain traction and Avalonia has grown and is far more the de-facto choice for .NET cross-platform GUI. Both work collegues and myself have ran into XAML/WPF Styling horrors where it's all one giant aggregation/inheritance nightmare generated by Blend (and done by someone that didn't quite know what they were doing)
It always seemed to me that a lack of gentle “WPF for Windows Forms developers” documentation was more of a problem here than WPF itself, which no more enforces the separation of presentation and execution than Windows Forms does, it just gives you more and higher-level options for how code interacts with the layout.
There was[0] Dabo, an attempt at a modern Visual Foxpro in Python https://dabo.leafe.com/
0: sort-of "is" rather than "was": https://blog.leafe.com/creativity-and-ai-models/
> I'm shocked in general at the lack of open source Rapid Application Development software.
They exist:
- In particular in the 90s and 00s, Tcl/Tk was really magic for creating user interfaces for small applications under GNU/Linux.
- Lazarus attempts to be an open-source analogue to Delphi
- LibreOffice Base attempts to fill the same niche as Microsoft Access
- Historically, in the time of Gtk+ 1.x and 2.x Glade [1] was an editor for clicking together user interfaces. Well, development ceased, and under GNU/Linux there is no attitude of retaining backwards compatibility with applications/libraries that are not maintained anymore (but which might be business-critical).
- ...
But of course Rapid Application Development is much more popular in the business world which is (at least in many European countries) a rather Microsoft-centric environment. Additionally, the typical developer that uses Rapid Application Development is often a subject-matter expert in some department who also knows a little bit about programming (i.e. is not in deep love with programming), and not a programming expert who also knows about some other specialized topics that are important for the business.
On the other hand, the open source environment typically rather attracts people who really like programming.
---
[1] https://en.wikipedia.org/wiki/Glade_Interface_Designer
Probably because *nix programmers in general are the black coffee long beard RTFM type.
There have been shitloads of open source RADs. They do not generate much interest.
If your into C++, there is U++ (Ultimate++), which is a fully featured RAD ide equivalent to Lazarus with the fastest compiler I've seen. It compiles to Win/Mac/Linux/BSD.
Well, (F)OSS projects have never been known for great UI/UX (with some exceptions like Blender), so it doesn't surprise me much
Qt Quick and Qt Creator isn't RAD per se but I feel like it gets you close.
Nerds have vested interests (exposure/influence/status based on exclusivity of skill) to oppose letting ”the wrong people” create software, versus a company like Microsoft is the other way around because they get paid and get to further-entrench their platforms (but I repeat myself).
And/or too many people have internalized a feeling of “I am Very Smart because I know better than to ever try anything unique”, as exemplified by that awful xkcd ‘Standards’ learned-helplessness comic somebody will always rush to post in a discussion of any New Thing, and thus would never even dream of creating RAD tools whose entire premise is the creation of bespoke software.
In the mid-2000's, I built a lot of applications replacing Access. I always met with the actual users of the system, and made sure they understood that once I took over development, they weren't going to be able to build out their own forms anymore. A few clients were turned away, but most could live with paying for myself to make any future edits, so that they could concentrate on the business objective rather than coding in Access. I never really had the same success with replacing Excel, except for a few systems where it needed to be true multi-user.
There's Gambas: https://gambaswiki.org/website/en/main.html
Lazarus/FreePascal: https://www.lazarus-ide.org/
Kivy: https://kivy.org/
Grails: https://grails.apache.org/
And any number of combinations using the web. I think they've just fallen off in popularity due to all the web interfaces, honestly.
There is openoffice base https://help.libreoffice.org/latest/en-US/text/sdatabase/mai...
I am not going to claim it is any good, it suffers from the same problem most rapid application toolkits have, the easy stuff is easier, the hard stuff is harder. I was playing around at one point to see if it was worth using as a graphical interface to a postgres database. And... it worked. But in the end I preferred writing web applications. As much as I hate web dev it was better than the RAD jank.
> Access is so good. I can't believe there's no universal equivalent for Linux and Mac.
Here you go: https://visualdb.com There are many modern alternatives, in fact.
I've looked into these before and they're often a monthly/annual SaaS that are either by a one-person company, or worse, something like AirTable that gets crazy price hikes out of nowhere (or shut down) that's a disaster for a small company. Place I worked already had Microsoft Office paid for so why move away from Access.
If it works for you then there is no need to switch. But Access is a desktop app, and in 2026 it is pretty unusual to use a desktop app for business applications. Also, Microsoft is no longer developing Access.
In 2026, Microsoft Access is still fully supported and bundled into Microsoft 365 Enterprise subscriptions. Back in 2014, I'd said to my employer that it's not going anywhere for at least a decade (and that they can fully ignore a report they'd received from the NDPB that oversaw their work that suggested Access might be at risk of disappearing)
>In 2026, Microsoft Access is still fully supported and bundled into Microsoft 365 Enterprise subscriptions.
Having a subscription is only a small part of the total cost. Access works best when combined with a bunch of VBS/macro scripts, which IT departments globally are trying very hard to stamp out completely. Access also needs its own set of permissions and manager of permissions since it can't inherit permissions from anywhere of the other usual Microslop security stores - at least, not without having its own developer/maintainer/champion on tap.
Not to mention the agreed wisdom that while Access is fantastic for rapid-prototyping applications/warehouses/ETL processes, any "permanent" DB/DBMS/solution worth doing in Access is worth doing in a 'proper' database with a proper front-end.
All true and yeah, I did discuss with my employer at the time about how they needed to think long term about migrating to SQL Server or MySQL/PostgreSQL with a web front-end. However, the giant IT contractor they were stuck with would only allow SQL Server and charge a fortune, and they didn't have the time/money/know-how to go anywhere with that. They were stuck with Access!
> Access works best when combined with a bunch of VBS/macro scripts...
You're thinking of Visual Basic for Applications (VBA), which is interpreted inside of Access. The standalone Visual Basic Scripting (VBScript) is a completely different thing, and eliminating VBScript doesn't have any ramifications for Access.
Ugh, yeah. VBA not VBS. I'd like to say "the keys are right next to each other", but the truth is I've been in both those worlds for far too long...
As long as it has a significant number of users Microsoft will keep shipping it. But it is not getting significant new investment. If you are building a new application you're better off using Power Apps, Dataverse, SharePoint, Power Automate, etc.
> Microsoft is no longer developing Access
I don’t think that’s true.
Have you seen "Weekend at Bernie's"?
That seems to be missing an actual database. Access has everything included. Run Access.exe and away you go. This looks way more complicated.
It includes SQLite
Technically, MS Power Apps is the successor to MS Access. Power Apps is a web application so that solves the cross platform problem.
Having played with it, it’s not as turn key as either MS Access or something like Airtable. It can be overly complicated and it’s infected with the paradox of choice.
Spec one.
Start one.
Has someone written on or otherwise worked on this?
Sqlite?
Access is a whole package with form designers, widgets, scripting, etc. so that you can build an entire distributable app from it. SQLite's a brilliant little DB but it only covers a tiny portion of what Access does.
I kinda loathe access for any number of reasons, but appreciate the dev tools it put into the hands of non-developers. A great many people who'd be passive users on most systems were able to build apps to meet their business and requirements, and although Access was janky as hell, that's very, very cool. I think it's most spiritually similar to HyperCard on Mac: you wouldn't want to write a whole large app in it, and if you're an experienced developer there are any number of tools you'd rather write programs with. But if you weren't a traditional developer (e.g. an office worker or a student or a home computer enthusiast, etc.) it gave you a pleasant hand-holding process for making your ideas come to life. I respect that.
I thought gambas was interesting but I didn't do much with it.
Gambas was neat. I think we also looked at Kivy at the time, and I think there were a couple of other Python RAD systems that aimed to be similar to VFP in spirit, although not even slightly compatible.
I loved visual fox pro as a kid (~10). I made little UIs to open my favorite sites and files.
>1 commit 2 hours ago
>domain registered 7 hours ago
>ghost pusher named Dev
Pretty sure all the upvotes came from folks nostalgic about FoxPro development days. I don't think anyone is actually upvoting the quality of the seemingly fully AI written website, documentation, and application.
My godfather that helped me get into computers used to make a decent living doing foxpro databases for companies in the 90s. We lost touch years ago, I always wondered if he stuck with it.
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.
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.
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.
The issue we face is CDX. We have >100 dbfs, and >600 clients hitting them at all times.
Would you trust foxscript? I'm curious if this is just a wide-net data exfil attempt.
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 wouldn't trust anything without further review.
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.
I have been working on a VB6 recreation starting with the IDE. Eventually I want to build the compiler and runtime, but for now being able to open existing projects, load all the images and do all the syntax highlighting is a good first step.
I know TwinBasic exists but its closed source and I want to take things further than VB6 ever did. I always felt like VB7 could have been something amazing if it kept going outside of .NET but they let it go and basically killed a really rich language by breaking all sane compatibility.
Maybe worth me putting support for this project, and I too intend to license my efforts under the MIT license. ;)
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 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.
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.
Without fail, these vibe coded project websites all make themselves look way more ambitious and established than they actually are. A software project could be hours old and it will have a website that, just a handful of years ago, only projects that had been around for a while and with a revenue model would have had. To me, it comes off as so overly persuasive that the only thing I can think nowadays is "what sort of half-baked junk are they trying to sell me?" Today, a primitive website or a mere handwritten README.md is, ironically, a more reliable signal of whether an application is worth considering. At least to me, anyway.
We need https://xkcd.com/1742/ but maybe with a different scale category.
Unlike most other people here, I wouldn't really say I've developed a radar for "the vibecoded webpage design"; I thankfully don't dabble as much with FE nowadays so if you told me this is default Bootstrap 4 or something, I'd have believed you. But as I scrolled through the claims, my AI-generated text radar pinged hard and I was caught in a moment of dissonance between the sleek design and the AI-cadenced copy.
Suddenly, I would've had more confidence if this was a black default font text on a white webpage, served from a .edu domain.
> The nightly is rebuilt from every push to main and published as a pre-release on GitHub. Unsigned, so the first launch asks you to confirm.
But with only two commits within the hour this really reads more like a concept of a release plan than an actual regimented/automated release process.
My problem with vibecoded projects was never whether if it was going to work but whether if the failure modes are known. And you can only know the failure modes if you check your work. Hence why, I realized that a history of alpha and beta releases for an opensource project is a signal of quality.
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
[flagged]
[flagged]
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.
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.
I was an undergraduate in the late 1980s/early 1990s and I worked part time in the university library working on databases and interfaces first in dBase III then Foxbase (the predecessor to Foxpro; basically an extended dBase III clone) then DOS FoxPro. I rather liked them, but this was long before I had ever seen SQL or anything like that. The weird thing was that my boss (besides being the library's IT guy) was a taekwondo instructor! What is it about FoxPro and that?
I'm wondering if it's the same guy. Without doxxing yourself too much, you didn't happen to be in the central Florida area did you?
Funny if it were, but I was in Wisconsin.
You are right because I've never touched Erlang, otherwise I did the same for a TKD studio as well.
I didn't do Erlang at the Tae Kwan Do studio, that was the FoxPro and ColdFusion (and ActionScript/Flex).
I have just had a lot of very odd jobs which has taken me in a bunch of directions.
modi comm taekwando
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.
DBF is a straightforward and widely implemented file format, so I assume LLMs would have little trouble extracting raw data. No idea about programmatic access, but I assume the answer is yes.
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.
Yup, same story for me. Father-in-law owned a consulting business on the side. (CS Professor was his day job) His apps were CA Clipper, DB3, VB4-6, FoxPro, Turbo Pascal, Delphi. I worked for him for years in college. Doctors offices, dentist offices and an oil company. What a time to be in the programming gig! I migrated Novell servers and moved customers from Btrieve to PervasiveSQL. We got into open source pretty early (1998 - which one might argue wasn't THAT early). Some of our "next-gen" stuff used Perl:DBI, Python + MySQL, PHP3. I got such a crash course in cool tech.
The one thing I learned early on. MS-JET is NOT something you want to share from a server! Dbase dbf on the other hand, seemed to work fine.
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.
Vernor Vinge's A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. <https://web.archive.org/web/20231114211656/http://www.gareth...>
(Heck, recently I migrated a VM to its third hypervisor. It began as a physical machine a quarter century ago.)
I too maintain a small fleet of virtualized copies of the silent machines which now still sit on the shelf, unpowered, nevertheless .. there if they are needed.
Vernor Vinge’s works have indeed had a huge impact on the way we think about things, and his immense insight is still extraordinary with every read.
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.
Didn't expect an AppImage and a .deb in the downloads. How much of an app survives on Linux, though? Plenty of VFP code drives Excel through CREATEOBJECT, and the .fll bridge is a 32-bit Windows process. What happens to those calls there?
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.
Ya so you can bill twice! Once to do it the way the customer wants and a second time to do it right once they realize their mistake.
MECHANIC
HOURLY RATE
$100/HR ==== STANDARD
$150/HR ==== IF YOU WATCH
$175/HR ==== IF YOU HELP
$200/HR ==== IF YOU WORKED ON IT FIRST
$250/HR ==== IF YOU TELL ME HOW TO DO MY JOB
The home page for Foxscript is perfect IMHO. Loads fast, well written, easy to understand, looks great.
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.
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
The runtime didn’t contain the debugger or other dev tools, only the dev version/IDE did. It did contain the report writer, though.
mmm.. I remember was a issue to let `SET STEP ON` on the codebase and I assume it opens the debugger...
I will concede the point, it was a long time ago. :-)
EDIT: I looked it up. Causes an error in VFP 6.0 and earlier, but not in VFP >=7.0.
While these tools were useful for their time, I agree with most of the sentiment that some genies are best left in the bottle.
Also, I would beware of getting MS lawyers on your tail.
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.
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.
what a great idea, and has the potential to pull $10m in a year or so. engineers everywhere should be pursuing these projects. So many businesses are running on "legacy" platforms. Glance over the costco customer service desk , they're still using some cobol dos inventory system.
Clone it with cheaper tools, and win the next $100m / yr contract from costco at half the price. There are 100k opportunities out there right now.
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?
Apple still sells Filemaker.
https://www.claris.com/filemaker/
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.
bigger tables (2 GB cap) and no source code changes.
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 :)
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 learned SQL with FoxPro on the Mac in the 90s. It was a great app.
Same, but not a Mac.
The lecturer had a side business building FoxPro apps for local businesses, and really pushed us with real-world style SQL puzzles.
Built an app to track my MtG cards at the time. (this was pre-Web)
Clarion and Paradox thought one of them was going to win the tontine.
R:BASE is still around
Neat! I tried to do the same for Filemaker Pro 10 (with Fable). Bit couldn't push it beyond 50% functionality.
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.
This reminds me of when I used to think it would be cool to rewrite Empire in COBOL.
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.
Someone really missed those `.dbf` files. Curious if the report writer is still a nightmare or a nostalgic dream.
Ugh. My first job was rewriting foxpro. Bad memories.
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.
For vibe coded open-source projects, I believe the prompt session/history should be shared as well.
What kind of use do you expect to get from them? Evaluate the amount human effort of the project?
I believe it would be helpful for those who would want to continue development, contribute to the project.
Pro-AI people now argue that the code is ephemeral nowadays, we should not look at it like we don't look at generated assembly (most of the devs). So in this regard, sharing only the "assembly" doesn't make sense, it's like sharing only the binaries and calling that open source (before LLM days).
I expect a real big-gish project would have possibly hundreds or thousands of such sessions. And personally I've never needed to dig back an old session for reference, only when I'm still actively working on the topic. They don't have a particular structure, whereas the actual code has a lot of structure.
But maybe it would be useful to have the related chats in the actual git commits that introduce the features. This way, if you (or the agent) `git bisect`s an issue, the same context that was used to construct the feature could be used for making the fix as well. I have never tried this approach, but it sounds like it could be useful.
It's slightly annoying that most (all?) harnesses store the chat logs in a db outside the project, and additionally e.g. OpenCode doesn't give the agent a direct way to access the complete current session context. So implementing this currently would be a bit hacky (find session by time? generate random string in context and find the session?).
I would absolutely love to interact with a demo program made using this FoxPro.
Wow, FoxPro! Used to build some gnarly inventory systems with that. Good to see it kicking.
Any love for Borland’s Paradox?
what was foxpro , for younger gen here
It was boxed software that, when going to a computer/office store as a child in the mid-1990s, you wanted your parents to buy because it had a fox on the cover and in the name without actually knowing what it did.
Simply speaking from experience.
An IDE, form designer, language, runtime, and database engine.
People used it to write business applications. Like Microsoft Access, or Visual Basic.
It started as a competitor to dBase II/III called FoxBase, and then Microsoft bought it.
Besides being a DB with forms, reports, etc as already mentioned by others - its significance was huge as it was the peak of an era where small/single developers could deliver business solutions by knowing a single tool, and people with domain knowledge could write their own solutions.
Since then everything became much more complex - networking, security, GUIs, web development, deployment, etc.
Original - FoxPro: https://en.wikipedia.org/wiki/FoxPro
Successor - Visual FoxPro: https://en.wikipedia.org/wiki/Visual_FoxPro
A tool and language to write apps where you could write "Select * from customers" in the command window and get results right there in a browse table, beautifully
Not a single language nowadays can do that
a database program, IIRC it was a program not by microsoft but MS bought it and killed it off
Yes, they bought it. But they didn’t buy it and stab it in the heart. They developed it for several years.
A primary bit of tech that came out of the purchase was the core DB engine. They reworked this into what became the Jet engine. The Jet engine was the core of Access.
Access was in many ways a next generation of FoxPro. They both went after the same niche of desktop and file server DB applications. But FoxPro carried the legacy of its dBase roots, FoxBase was basically “better dBase”, but had to appeal to and be familiar to dBase developers.
Access had no heritage like that to hold it back, and was a better citizen in the VB/Office/OLE/COM world. It was also more SQL first even though it kept things like DBF files as first class citizens.
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).
What's wrong with the Sigstore ecosystem? Why reinvent this wheel in particular?
Asfaload takes different technical decisions:
- multisig approach: you can require multiple signers to sign a release for it to be accepted by downloaders. Protects against account compromise. Sigstore relies on OIDC, but this makes it often reliant on megacorps (and harder to self host, see next point)
- very easy to self host. You can deploy it internally without any problem, eg in an airgapped environment where you want to distribute signed artifact. This is impossible with Sigstore.
- accountless: the key is the identity. The multisig approach diminishes the problems that long-lived keys might bring. And you don't rely on an external OIDC provider to be able to sign.
- Air-gapped signers: it is possible to have air-gapped signers, as signing does not rely on an online service to verify an identity.
- easy for downloader: the use only has to provide the download url, and this is sufficient to authenticate the download.
- easy to audit: the backend data is stored in a git, that will be mirrored in different places, and anyone can mirror it for themselves.
You might agree or not with these choices, but there are enough differences to say that it doesn't reinvent the wheel, it's providing another approach which I think has its advantages.
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!
This is great! Next up: VB6
[dead]
Very nice one of my favorite revivals ever. Kudos.
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?
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.
Is it less performance if you compare the hardware it was probably running on vs today?
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.
Since vibe-coding solved the issue of manpower, why stick to Electron and js frameworks?
must have been a rich customer!
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!
I legit hate reading AI slop speak.
It's so annoying now. It's like everyone spamming each other with AI slop.
Hahahah this is too funny 8)
I wished almost it was terminal based
Cool - now do Lotus Approach
Why stop there? What the world truly needs is a vibe-coded Lotus Notes!
Notes - It’s got what clankers crave.
Ah yes, yet another reason not to bury the dead.
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?
The website at least. Just look for the word "not". LLMs love writing things like "it's not ice cream, is pasta", "you get a full dog, not a cat".
"Every picture is a real session."
Dead giveaway.
Probably. The website does look too good though, none of the design cruft ("eyebrows") that LLMs like. But the last design I let it do was from opus 4.7 or gpt 5.3.
It does look very LLM-y to me, the copy certainly is.
Yeah, you're right. The models have just gotten better at design.
Obviously they used AI at some point in the project, the question to you is what is your definition of vibe coding and how does it discredit the effort they did put into it?
One benchmark would be: would someone with a legacy FoxPro LOB app be entrusting their data to this? Or is it just a nice "wow, that's a cool project"?
There's a continuum between vibe coded and directed LLM, I guess we'll see which it is.
The post comment here is 100% packed with LLMisms, so yes.
The website is obviously and gratingly LLM-voiced. I don't know how people aren't tired of paragraphs like this yet:
"Visual FoxPro is a 32-bit program, and that decides more than it appears to. It is why a table stops at two gigabytes, why a memo file stops at two gigabytes, and why a big report runs out of memory on a machine with plenty to spare. The limits are signed 32-bit numbers buried in the file handling, not a licensing decision anybody made."
and
"The editor checks what you type through that very compiler, so what it underlines and what the runtime refuses cannot drift apart."
Like, what? Who talks like that?
To me, this is not worse than any Apple marketing page from the last 15 years written by human marketing people.
Right, yes, this sort of style certainly can be produced by writers, especially ones who are working in a particular corporate universe. That's where LLMs got it from! It just sucks that everyone "writes" like that now. Every new one-person project or company is incongruously spouting corporatese. Don't we get enough of that already? Flattening everything into American corpo-speak sucks.
Okay but why should one expect a marketing site, which this is, to have quality prose instead of typical marketing prose, which it does.
Robots (by default).
Take the time to ask for anything else.
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
[dead]
[flagged]
[dead]
[flagged]