One of the original Fox developers wrote a great behind-the-scenes book about the software and the company culture, uptil their acquisition by Microsoft.
It is one of the more niche, under-appreciated technology books out there: "FoxTales: Behind the Scenes at Fox Software" by Kerry Nietz
FoxPro was originally FoxBase, a clone of dBase III, and in some respects better than dBase - IIRC, it could handle larger files, and worked better on a Novell Netware. FoxBase was however a console application - no windowing and no mouse.
Then in the beginning of 1989, they started working on "FireFox" - that's where the classic FoxPro GUI came to life. It was a big departure from dBase, and the name went thru multiple iterations before it became FoxPro. It was a runaway success. dBase never caught up - dBase IV tried catching up with FoxPro's GUI, but it was buggy, slow, and its lunch was being eaten by Nantucket's Clipper compiler.
It was fun times, but sadly the xBase dialect wars were superseded by the rise of Windows, and by the time people retooled into Delphi and Visual Basic, that went away and the web became the dominant application platform.
correction: dBase IV came out before FoxPro. From the book:
"By the beginning of summer ‘89, FoxPro was turning into an impressive product. As an outgrowth of the new language added to emulate dBase IV, and our new window-based interface, many items present in earlier Fox products were substantially transformed."
Kerry continues:
"By the beginning of summer ‘89, FoxPro was turning into an impressive product. As an outgrowth of the new language added to emulate dBase IV, and our new window-based interface, many items present in earlier Fox products were substantially transformed.
One of these was our text editor. Two commands in the language would present this to a user, MODIFY FILE and MODIFY COMMAND. In FoxBASE+, the editor was simplistic. It just filled the screen with whatever file was being edited. Only one file could be edited at a time, and there was a rigid limit to how big that file could be. It was functional for developing dBase programs, but most hardcore users would buy an additional editing program to do real text editing work.
As coded by Eric, though, the new FoxPro editor was an animal of a different color (no pun intended). It resided in a window and users could have as many text files open concurrently as they liked. They could easily copy and paste text between different files. There was no limit to the size of the file. (No attainable limit, anyway; the actual limit for a text file was larger than most modern disk drives.) It was also blindingly fast. It could open hundreds of files in seconds and scroll text faster than it could be read."
They were bought by Microsoft when they released a version of FoxPro with "rushmore", that made it many times faster than the competion. I still remember the adds.
Foxpro is top notch. And I have never used it. Here is why:
- My former best friend has created a software in 1995 that manages 30% of all vendor machine ( coffee, candy bars, sandwich) in Europe.
The software uses Foxpro.
1) He tried twice to migrate to other dev tools. Never succeed.
2) His software is so good his company was in average 40% more profitable then competitors.
3) His CEO has bought 10 competitors of the same size in 20 years. Each time my friends software would replace the former. Than the financial margin would go up.
In the 90s I knew several similar cases where significant companies were run on FoxPro or Access. I don't think there are any web based tools on the market now where you could achieve the same thing with the same level of effort.
I wonder if Microsoft could just open source it now. I can't imagine they're making money from it in 2021 and this would definitely add to the community goodwill towards them, which they definitely lack.
The whole xBase universe is quite fascinating. It might not have been as revolutionary as spreadsheets, but having databases on your homecomputer/PC covers a lot of use cases for regular people and small businesses. Heck, a lot of what we make way too much money with is basically "just" polishing that. (Or trying to sell you pills while you use that, but let's not digress)
And dBase and its variants/rivals had that pretty much covered, from CP/M to Ataris to DOS and later Windows. Also begat a wide spectrum of programming it, from simple end-user customization to pretty large multi-person applications.
But now? The whole xBase/Clipper-verse almost seems like a unique dead end, in an industry that keeps pretty much every other technology afloat. And it doesn't even seem that that is purely for technical reasons. Sure, client/server and more powerful machiens meant that "proper" RDBMS were getting common, and with environments like Visual Basic or Delphi you could create some pretty neat frontends.
But that was only part of it. Bad acquisitions were another one, with Borland buying dBase and Microsoft buying FoxBase. Not before the dBase makers were a bit too litigious, which doesn't really help trust in the market and individual products.
Right now, the most prominent products still somewhat in line with that would be Access and FileMaker, and they seem slightly different beasts. Or maybe even cloud-based data buckets like Firebase, but they don't quite seem as "egalitarian". And while NoSQL database might claim some relationship, their usage patterns are quite different.
> Heck, a lot of what we make way too much money with is basically "just" polishing that.
No one wants to admit it, but 80% of "Enterprise IT" revolves around "CRUD app on top of a database". The other 20% mainly revolves around either running reports off the data in that database or interfacing it with some other system. Been this way for decades.
Maybe it is is "CRUD" in practice, but often it shouldn't. There ist way too much business software with ugly hacks like misused data fields, endless data repetition, manual steps and the like. That might be "good enough" in many cases, but it comes with risk and high costs. Software supporting actual business processes using "domain objects" would be way better.
And of course many editions of MS Office include Microsoft Access, which undoubtedly had a role to play in killing dBase, Borland’s Paradox, and Lotus’s Approach.
Access’s not quite as pervasive as Excel but I'm sure a bunch of VBA die-hards in various industries still use it, at least for prototyping.
FileMaker's quiet, sustained success over the years makes you wonder why Microsoft didn't spin off FoxPro in the same way that Apple spun off Claris. Perhaps they were worried it would be too competitive with their own core products?
Quick shoutout to xHarbour and Harbour - the open-source, commercially-supported versions of Clipper. https://github.com/harbour/core
The projects are still going strong and many years ago I had ported a huge Clipper project into Harbour and had it working well across a 20 node network with both Clipper and Harbour binaries working simultaneously on the same database.
These days every time I make another web application I wish for the simplicity of xBase. But there is some core truth about application development hidden there that is lost to me now.
My parents' small business had all kinds of reporting views (one would print envelopes) from their Lotus Approach database. It's been quite the downgrade to migrate to Excel from this. (Access, wherever it exists, it's just not as simple as GUI desktop DBs).
Wow...this brought back some memories of supporting FoxPro and dBASE users back in the day!
I always wondered, back then...if these people were really so strangely amazing with their DB front-ends, why not get a CS degree? Or study IT like us pros who were helping troubleshoot? (They were educated, but in strange-to-us areas like accounting)
Now I look back and wish I had spent more time listening to their stories and hearing about favorite experiences in putting their own tools together, and less time blaming their software for weird stuff. ;-) We had an office full of cards. From OS/2 guys to proprietary database people, from hardcore WordPerfect fans (Corel what...!?) to the Mac folks one building over, and their interesting networking issues...on top of our Novell network...oh and by the way, there's a cash register attached to a computer in building such-and-such, that makes it our job to fix, right? (Fixed register drawer with an excess amount of grease I found in an old toolbox; call boss with questions)
I do think there's a lost appreciation for those who aren't "pure technologists". My father-in-law was a draftsman, who was tasked with eventually getting up to speed with CAD. His knack for it led to him having responsibility for installing and teaching others, and eventually led to him working in general IT at places like Schlumberger.
Foxpro had an embedded db engine and so SQL commands could be used directly in the language for fetching data, which made it fantastic for CRUD database apps, which is what nearly all applications were back in those days. The 'tables' we're just dos files that could sit on a network drive to make the application multi-user. I think there was some limitation with the SQL, e.g. no outer joins, but it was still very handy.
MS continued to support foxpro somewhat into the .net era but then it fell to the wayside. When Linq arrived for c# it made me smile because it harks back to FoxPros embedded SQL, although of course Linq represents a _lot_ more than just embedded queries.
It was flexible too - my all-time favourite application of FoxPro is Island ECN, one of the first big Alternative Trading Systems and a direct ancestor to NASDAQs current INET platform.
Nice! Reading that code brings back memories... 1990 (around) I did a lot of work in dBase & Clipper & fox pro; it was easy to work with and, because in the Netherlands it was not that popular, I could get excellent job as 16-17 year old for the summer, working on admin systems for factories that used dbase & clipper.
I remember porting some of those systems to Java half a decade later and asking myself if this was a good direction; Java looked so... crude at the time compared to these technologies.
At least two major doctor/hospital softwares in my country still use FoxPro. But new features piled on top of decades old code base make it pain in the ass to use. (i.e. online communication with health insurance company halts the main program and launches a communication program every now and then)
C # creator Anders Hejlsberg made a statement a few years after the .net platform came into being, recognizing that data was very important and admitting that they were developing linq.
It would be interesting to get that statement, because .NET original plan was to be what WinRT is.
A improvement over the COM runtime with better tooling, but then they pivoted the idea with J++, and had to reboot it with .NET for the reasons we all know.
It was relatively rare to see SQL in idiomatic FoxPro of old, and more typical to work directly with indices, or use SCAN .. ENDSCAN. That was partly what made it so fast.
2.0 was the first version that changed it, to some extent, because it included the Rushmore query optimizer, which was actually pretty good. But veteran developers didn't trust it much even so.
What's especially interesting is that UI code was actually compatible between DOS and Windows versions, so long as you didn't use any platform-specific features (which were mostly Windows-specific, so most DOS apps could be ported very easily).
By orders of magnitude, my most popular open source release was a project to help people migrate from FoxPro to PostgreSQL: https://github.com/kstrauser/pgdbf
FoxPro was cool for desktop apps, but couldn’t make the leap to networked clients, where “networked” was more than “has access to the file share where the database files live”.
In the early 2000s I was hired to write a website that published reports from data stored in a Visual FoxPro database. A not-so-fun fact I learned: the VFP database libraries are single-threaded at the OS level. That is, you couldn’t run more than one query on the same machine at the same time, even in different processes. One would block until another finished. In a fit a panic and madness, I ended up writing an XMLRPC service (“which was the style at the time”) in Python, deploying it to multiple old Windows XP desktops we had laying around, and writing a database adapter for the web server that would send queries to those servers round-robin. Need more parallelism? Add another Windows XP box running my janky little service. It was awful, but it let us ship the project.
Later I wrote pgdbf so that we could run a cron job that would copy all our data out of FoxPro into PostgreSQL so that I could code against a real multi-user database that was vastly better in every way. By accident, I released it at a time when the world was wondering how they were going to migrate from FoxPro to something else. Turns out VFP was wildly popular in South America, and pgdbf turned out to be wildly popular there too, which let to me getting lots of email in Spanish and Portuguese and offers to come talk at user groups. I turned those down because what was I gonna say, “yeah, it was painful for me, too. Anyway, here you go and good luck!”?
VFP was crippled, like intentionally, by MS. Fox was absolutely superior to Access and SQL Server at the time (ie: as for build productive apps).
But the engine have so many quirks that affect their reliability (I still remember any fox app have the "rebuild indexes" and "fix corruption" in the menu of the app!)
This was purely a ploy, I think. Then Fox was killed and now millions of hours are wasted doing what fox allow in minutes.
FoxPro 2.x was fast and easy to use, this made it enormously popular back in the days. In mid to late 90' it was the first choice for most apps, even in small to medium companies. The success was coming from performance and ease of use.
In the 90' Turbo Pascal and FoxPro were languages that anyone could understand and use quickly without a lot of training. It made it accessible for learners with or without CS background, so I had many colleagues that knew and wrote a bit of FoxPro 2.6 for their needs - from small task automation to entire apps covering what the company IT was not able to do because it was not a priority.
Fast forward 30 years, the situation is not better, even if one would expect progress. We have hundreds of languages, the language landscape is way too fragmented. Do you want to write some code? Jim will do X, Joe will do Y and Jane will do Z and they will use different languages and everything will not be compatible and they will not understand each other's code. For data we have SQL and we have ANSI SQL which makes it partially compatible, that is great, but for general coding... no. And if you want to write a small data app you cannot just fire up FoxPro, you need to install a SQL server of sort, configure it (and that can be a small dark art in cases), get something like VS Code and write in a language that will not be SQL, but will interact also with SQL. Too complex, too complicated, too easy to give up. And if you want to explain to a non-IT person OOP and why a single line of WriteLine('Hello World') needs a class and a method and what is OO using the old story 'imagine you have animals, and some animals are mammals and mammals can inherit properties from the animals class' just to write Hello World on the screen, then we have a problem of accessibility: 'Man, I just want to write 2 words on that bloody screen!'.
So this is why FoxPro was easy to use: just fire it up and write some code, there is not much to prepare and nothing much you can break. And no dependency management, no unsafe downloads from all over the Internet, you can learn everything in a week and forget it in a year.
Readit News
It is one of the more niche, under-appreciated technology books out there: "FoxTales: Behind the Scenes at Fox Software" by Kerry Nietz
FoxPro was originally FoxBase, a clone of dBase III, and in some respects better than dBase - IIRC, it could handle larger files, and worked better on a Novell Netware. FoxBase was however a console application - no windowing and no mouse.
Then in the beginning of 1989, they started working on "FireFox" - that's where the classic FoxPro GUI came to life. It was a big departure from dBase, and the name went thru multiple iterations before it became FoxPro. It was a runaway success. dBase never caught up - dBase IV tried catching up with FoxPro's GUI, but it was buggy, slow, and its lunch was being eaten by Nantucket's Clipper compiler.
It was fun times, but sadly the xBase dialect wars were superseded by the rise of Windows, and by the time people retooled into Delphi and Visual Basic, that went away and the web became the dominant application platform.
"By the beginning of summer ‘89, FoxPro was turning into an impressive product. As an outgrowth of the new language added to emulate dBase IV, and our new window-based interface, many items present in earlier Fox products were substantially transformed."
Kerry continues:
"By the beginning of summer ‘89, FoxPro was turning into an impressive product. As an outgrowth of the new language added to emulate dBase IV, and our new window-based interface, many items present in earlier Fox products were substantially transformed.
One of these was our text editor. Two commands in the language would present this to a user, MODIFY FILE and MODIFY COMMAND. In FoxBASE+, the editor was simplistic. It just filled the screen with whatever file was being edited. Only one file could be edited at a time, and there was a rigid limit to how big that file could be. It was functional for developing dBase programs, but most hardcore users would buy an additional editing program to do real text editing work.
As coded by Eric, though, the new FoxPro editor was an animal of a different color (no pun intended). It resided in a window and users could have as many text files open concurrently as they liked. They could easily copy and paste text between different files. There was no limit to the size of the file. (No attainable limit, anyway; the actual limit for a text file was larger than most modern disk drives.) It was also blindingly fast. It could open hundreds of files in seconds and scroll text faster than it could be read."
http://www.foxprohistory.org/rushmore.htm
- My former best friend has created a software in 1995 that manages 30% of all vendor machine ( coffee, candy bars, sandwich) in Europe. The software uses Foxpro.
1) He tried twice to migrate to other dev tools. Never succeed.
2) His software is so good his company was in average 40% more profitable then competitors.
3) His CEO has bought 10 competitors of the same size in 20 years. Each time my friends software would replace the former. Than the financial margin would go up.
And dBase and its variants/rivals had that pretty much covered, from CP/M to Ataris to DOS and later Windows. Also begat a wide spectrum of programming it, from simple end-user customization to pretty large multi-person applications.
But now? The whole xBase/Clipper-verse almost seems like a unique dead end, in an industry that keeps pretty much every other technology afloat. And it doesn't even seem that that is purely for technical reasons. Sure, client/server and more powerful machiens meant that "proper" RDBMS were getting common, and with environments like Visual Basic or Delphi you could create some pretty neat frontends.
But that was only part of it. Bad acquisitions were another one, with Borland buying dBase and Microsoft buying FoxBase. Not before the dBase makers were a bit too litigious, which doesn't really help trust in the market and individual products.
Right now, the most prominent products still somewhat in line with that would be Access and FileMaker, and they seem slightly different beasts. Or maybe even cloud-based data buckets like Firebase, but they don't quite seem as "egalitarian". And while NoSQL database might claim some relationship, their usage patterns are quite different.
No one wants to admit it, but 80% of "Enterprise IT" revolves around "CRUD app on top of a database". The other 20% mainly revolves around either running reports off the data in that database or interfacing it with some other system. Been this way for decades.
Interestingly Claris's FileMaker is still in business: https://www.claris.com/filemaker/pro/
And of course many editions of MS Office include Microsoft Access, which undoubtedly had a role to play in killing dBase, Borland’s Paradox, and Lotus’s Approach.
Access’s not quite as pervasive as Excel but I'm sure a bunch of VBA die-hards in various industries still use it, at least for prototyping.
Amen. Add also Nantucket (Clipper) being acquired by CA (Computer Associates) which pretty much killed Clipper.
The projects are still going strong and many years ago I had ported a huge Clipper project into Harbour and had it working well across a 20 node network with both Clipper and Harbour binaries working simultaneously on the same database.
These days every time I make another web application I wish for the simplicity of xBase. But there is some core truth about application development hidden there that is lost to me now.
I always wondered, back then...if these people were really so strangely amazing with their DB front-ends, why not get a CS degree? Or study IT like us pros who were helping troubleshoot? (They were educated, but in strange-to-us areas like accounting)
Now I look back and wish I had spent more time listening to their stories and hearing about favorite experiences in putting their own tools together, and less time blaming their software for weird stuff. ;-) We had an office full of cards. From OS/2 guys to proprietary database people, from hardcore WordPerfect fans (Corel what...!?) to the Mac folks one building over, and their interesting networking issues...on top of our Novell network...oh and by the way, there's a cash register attached to a computer in building such-and-such, that makes it our job to fix, right? (Fixed register drawer with an excess amount of grease I found in an old toolbox; call boss with questions)
MS continued to support foxpro somewhat into the .net era but then it fell to the wayside. When Linq arrived for c# it made me smile because it harks back to FoxPros embedded SQL, although of course Linq represents a _lot_ more than just embedded queries.
The matching engine was written in FoxPro for DOS! --- the source code is here-> http://josh.com/notes/island-ecn-10th-birthday/
I remember porting some of those systems to Java half a decade later and asking myself if this was a good direction; Java looked so... crude at the time compared to these technologies.
A improvement over the COM runtime with better tooling, but then they pivoted the idea with J++, and had to reboot it with .NET for the reasons we all know.
https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/p...
2.0 was the first version that changed it, to some extent, because it included the Rushmore query optimizer, which was actually pretty good. But veteran developers didn't trust it much even so.
Worth it just for the very nostalgic Windows 3.1 controls.
http://www.dfpug.de/loseblattsammlung%5Cmigration%5Cwhitepap...
https://twitter.com/dosnostalgic/status/826566061793345536
It even had a visual GUI editor, and a visual report editor:
https://imgur.com/a/174ZAww
What's especially interesting is that UI code was actually compatible between DOS and Windows versions, so long as you didn't use any platform-specific features (which were mostly Windows-specific, so most DOS apps could be ported very easily).
FoxPro was cool for desktop apps, but couldn’t make the leap to networked clients, where “networked” was more than “has access to the file share where the database files live”.
In the early 2000s I was hired to write a website that published reports from data stored in a Visual FoxPro database. A not-so-fun fact I learned: the VFP database libraries are single-threaded at the OS level. That is, you couldn’t run more than one query on the same machine at the same time, even in different processes. One would block until another finished. In a fit a panic and madness, I ended up writing an XMLRPC service (“which was the style at the time”) in Python, deploying it to multiple old Windows XP desktops we had laying around, and writing a database adapter for the web server that would send queries to those servers round-robin. Need more parallelism? Add another Windows XP box running my janky little service. It was awful, but it let us ship the project.
Later I wrote pgdbf so that we could run a cron job that would copy all our data out of FoxPro into PostgreSQL so that I could code against a real multi-user database that was vastly better in every way. By accident, I released it at a time when the world was wondering how they were going to migrate from FoxPro to something else. Turns out VFP was wildly popular in South America, and pgdbf turned out to be wildly popular there too, which let to me getting lots of email in Spanish and Portuguese and offers to come talk at user groups. I turned those down because what was I gonna say, “yeah, it was painful for me, too. Anyway, here you go and good luck!”?
But the engine have so many quirks that affect their reliability (I still remember any fox app have the "rebuild indexes" and "fix corruption" in the menu of the app!)
This was purely a ploy, I think. Then Fox was killed and now millions of hours are wasted doing what fox allow in minutes.
In the 90' Turbo Pascal and FoxPro were languages that anyone could understand and use quickly without a lot of training. It made it accessible for learners with or without CS background, so I had many colleagues that knew and wrote a bit of FoxPro 2.6 for their needs - from small task automation to entire apps covering what the company IT was not able to do because it was not a priority.
Fast forward 30 years, the situation is not better, even if one would expect progress. We have hundreds of languages, the language landscape is way too fragmented. Do you want to write some code? Jim will do X, Joe will do Y and Jane will do Z and they will use different languages and everything will not be compatible and they will not understand each other's code. For data we have SQL and we have ANSI SQL which makes it partially compatible, that is great, but for general coding... no. And if you want to write a small data app you cannot just fire up FoxPro, you need to install a SQL server of sort, configure it (and that can be a small dark art in cases), get something like VS Code and write in a language that will not be SQL, but will interact also with SQL. Too complex, too complicated, too easy to give up. And if you want to explain to a non-IT person OOP and why a single line of WriteLine('Hello World') needs a class and a method and what is OO using the old story 'imagine you have animals, and some animals are mammals and mammals can inherit properties from the animals class' just to write Hello World on the screen, then we have a problem of accessibility: 'Man, I just want to write 2 words on that bloody screen!'.
So this is why FoxPro was easy to use: just fire it up and write some code, there is not much to prepare and nothing much you can break. And no dependency management, no unsafe downloads from all over the Internet, you can learn everything in a week and forget it in a year.