A modern IDE and 64-bit runtime for Visual FoxPro 9 applications: the same language, rebuilt on Electron, React and a Rust virtual machine in WebAssembly.
270 comments
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.
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...
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?
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...)
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.
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.
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 is alive. https://www.embarcadero.com/products/delphi
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.
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.
I thought everyone was on monorepos to "solve" that.
> And to the Author of the project. Thank You for making it. My pleasure
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.
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.
If you already have full access by design, then there's no "huge security hole" either.
It ships database files over the network and does that blazingly fast.
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.
I don't know if dBASE variants support bind variables. That isolation is really required to avoid the "Bobby Tables" effect.
I'd prefer to see the dBASE language adapted to run on SQLite files, as they are a far more profound standard.
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.
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.
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.
Do you spot any opportunities for new solutions in the real estate space these days?
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. :) )
Read the full thread on Hacker News →
Related stories
- DEV Community · 6 points · 4 days ago
- The Verge · 0 points · 6 days ago
- The Verge · 0 points · 6 days ago
- Microsoft stops insisting you need a "Copilot+ PC"arstechnica.comArs Technica · 0 points · 5 days ago
- Ars Technica · 0 points · 13 days ago
- The Verge · 0 points · 6 days ago