Visual FoxPro stopped at version 9 in 2007. A surprising amount of it is still running, in 32 bits, because rewriting a 20-year-old business app is how you lose the business. A customer wanted to keep milking their app for the foreseeable future, so here it is: the same language on a new runtime (Rust, compiled to wasm, checked against the real vfp9.exe), tables no longer stopped at 2 GB, the old 32-bit .fll add-ins still loading, and lambdas, JSON and an HTTP server bolted on for good measure. Reports are not done and the builds are unsigned. MIT because why not?
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
72% Positive
Analyzed from 4227 words in the discussion.
Trending Topics
#foxpro#access#app#https#database#software#business#microsoft#more#write

Discussion (111 Comments)Read Original on HackerNews
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.
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.
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.
In the case of your hash gambit since the attacker has access to the executable they can just patch-out the hash check.
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).
I also think it won't be that hard to make it multiuser, that's a long-ago solved problem these days.
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."
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.
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.
[0]https://github.com/kstrauser/pgdbf
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 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. :) )
If they do, immediately copy the data over. They tend to crumble and fall apart (and contaminate the drive head, which will need cleaning)
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?
I hate that it's the hand I'm dealt, but aside from AI rewrites (underway), there's no good answer. It's complicated by our reliance on DBFs.
I welcome efforts like foxscript and anything else in this space. There are still a significant number of FoxPro apps out there and no one has a good answer. If you are struggling in this space, leave a comment here. I'll reach out to you. Strength in numbers...
I 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.
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...
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.
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
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.
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.
Here you go: https://visualdb.com There are many modern alternatives, in fact.
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.
>domain registered 7 hours ago
>ghost pusher named Dev
Now 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
(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 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.
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.
Now, who's open sourcing and reviving FileMaker that Apple killed?
https://www.claris.com/filemaker/
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.)
Simply speaking from experience.
Not a single language nowadays can do that
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.
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)
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.
I wished almost it was terminal based
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?