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.
That’s great! Nice work thanks for sharing. I’ve never heard of FoxPro but I’ve seen how businesses need some app for 30+ years. Cool to see this happen.
Great job! 32-to-64-bit conversions are always fun :) One question though. If this is intended for desktop, why bother with WASM at all? Do you gain anything other than less performance?
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.
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
My father built several projects in FoxPro. I was too young in the ’90s to remember much of it, but I’m sure he’ll be super happy to check this out. The kicker is that we’ll probably need to buy a floppy disk drive and dust off some old boxes to find them.
I might literally be the only person on earth that can honestly say I have been paid to write FoxPro, Erlang, F#, and ColdFusion.
My first software job was at a Tae Kwan Do studio who ran their own billing department, and the entire billing half was some weird custom thing written with FoxPro. Not Visual FoxPro, I've never actually used that, but the old school DOS stuff.
I absolutely hated every time I had to touch it and I had hoped that it would die in a fire. I hope Visual FoxPro sucks less.
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?
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.
> 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.
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.
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.
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
Fuck you. Put the bare minimum of effort or thought into something you claim to have made before spamming it online like it's an achievement. You didn't make this or do real work. You're functionally indistinguishable from a spambot and just want attention for zero effort.
This is awesome! Having had to deal with ancient file formats knowing that there are renewed tooling that's not binding to legacy OSes that you can't no longer find viably is great.
Now, who's open sourcing and reviving FileMaker that Apple killed?
A company I worked for has run VFP up until the last few years. I cut my teeth professionally with it on ETL processes. It moved data around like nobodies business!
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 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.
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 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 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.
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 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.
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.
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.
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
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.
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.
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 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).
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.
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.
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 that the combination of AI coding tools plus headless EHR platforms 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.
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.
My recommendation is to get rid of the DBF/DBC files and move to a SQL DB of some flavor ASAP.
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 "certified" (wrong terminology) Board of Elections voter registration databases for Ohio is written in VFP and has TOTP 'MFA' to comply with a Secretary of State mandate.
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.
That doesn't add any actual security, though. An attacker can just manipulate the data directly without using the runtime if the data is directly accessible to the attacker.
In the case of your hash gambit since the attacker has access to the executable they can just patch-out the hash check.
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.
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.
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, 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. Most of the time, “full access to data” doesn’t necessarily mean “run arbitrary code”. In this case, it does.
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.
> 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!
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.
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 with religious zeal.
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.
234 comments
[ 0.28 ms ] story [ 20.1 ms ] threadNow your customer has two problems instead of just one.
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
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.)
(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
If they do, immediately copy the data over. They tend to crumble and fall apart (and contaminate the drive head, which will need cleaning)
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 have just had a lot of very odd jobs which has taken me in a bunch of directions.
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.
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.
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.
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.
Now, who's open sourcing and reviving FileMaker that Apple killed?
https://www.claris.com/filemaker/
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.
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.
Here you go: https://visualdb.com There are many modern alternatives, in fact.
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...
We didn't date for long, but I'd be curious to know how long that system ran.
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.
Start one.
Has someone written on or otherwise worked on this?
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.
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.
Successor - Visual FoxPro: https://en.wikipedia.org/wiki/Visual_FoxPro
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.
Not a single language nowadays can do that
Since then everything became much more complex - networking, security, GUIs, web development, deployment, etc.
I wished almost it was terminal based
[0]https://github.com/kstrauser/pgdbf
Dead giveaway.
"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?
Take the time to ask for anything else.
All the comments are also inauthentic and weirdly sycophantic reviews from new accounts.
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).
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."
Although to your point, it struggles to do anything with SQLite beyond a single user even when its architecturally not a problem
I also think it won't be that hard to make it multiuser, that's a long-ago solved problem these days.
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.
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)
My recommendation is to get rid of the DBF/DBC files and move to a SQL DB of some flavor ASAP.
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.
You can just open the database files directly.
I hang my head.
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.
In the case of your hash gambit since the attacker has access to the executable they can just patch-out the hash check.
If you already have full access by design, then there's no "huge security hole" either.
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.
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.
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.
Is there any local/native application for which this is not true?
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.
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.
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.
A significant weakness?
A serious limitation for modern uses / in modern environments?
It is top 6 in their vulnerabilities ranking.
This is definitely insecure design.
It ships database files over the network and does that blazingly fast.
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.
The permissions exploits on SQLite and dBASE are identical, sad to say.
You're a good guy. I respect you.
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.
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.
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!
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.
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 with religious zeal.
- written from my treadmill
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.