Down my memory lane – FoxPro and xBase
I started my programming way back in my 8th Standard (8th Grade) with GWBasic. Then during my high school moved to FoxBase+ and Clipper. I still remember the joy of my first Basic program running – as a matter of fact, my very first program was actually written in a paper before I was permitted by my “Basic” tutor to key it into a PC.
My exposure to serious programming was with FoxBase+ while attempting to enhance a simple Invoicing application written to run in MS-DOS 4.0 (Do you remember this OS?). Then at my family business, they bought a custom-developed Inventory Management written in Clipper Summer 87. The consultant who developed it abandoned us during a Virus attack (strangely he had the entire source code only on our machine and we lost it) and I had to reverse engineer the application and develop it afresh in FoxPro. Thanks to my Uncle Mr T.N.C.Veeraraghavan who actually pushed me into doing this project. If not for him I was merrily playing Games and experimenting with PCTools. PCTools was a suite of power tools for MS-DOS that allowed you to extend beyond the limits of DOS – the good thing about using it was that it allowed me to understand the PC Architecture and File System very well. PCTools was eventually bought and amalgamated into Symantec’s Norton Utilities.
My first attempt at doing the application with FoxPro was disastrous. Though I got the DB Schema, Screen and Reports working reasonably well; the application will run out of memory (remember the 640KB and 1MB Memory) after a few screens. It turned out that when the user closes a screen and wants to go back to the main screen, I was doing things totally wrong. Instead of calling the “EXIT” function to get out of the current function and return to the callee, I was basically calling again the main function. So within a few calls, the stack was getting overflowed. Though I am explaining what happened then very well now, I was clueless at that time and had to go to an expert – Mr Shivraj of Sysreader Magazine, who asked me “Venkat, why is that your functions don’t end!”.
After that, I immersed myself in FoxPro books and manuals (no Internet was available those days) and finally got the application working correctly. And it did work correctly for the next 10 years. Moving from one machine to another over the years and on the way seeing various versions of OS – MS-DOS 4/6, Windows 3.x, Windows 95, Windows 2000 and finally Windows XP. The remarkable thing was during these 10 years, no one had ever (almost) touched the source code or taken more than 10 minutes to backup/restore/set it up in a new machine. Around 2002, I was fed up with this MS-DOS application, so replaced it with a Visual Basic Application. The new VB application did pretty much the same functionality as the old FoxPro application, except this time it was a Windows Application.
After my stint with FoxPro, I graduated to Nantucket Clipper in Summer ‘87 for a short while and then to CA-Clipper 5.x. CA-Clipper 5.x was my stint on Object Oriented Programming (OOPS) and I still cherish my first full-fledged OOPS application for a fleet management system – but that story and details are for a different day!
Coming back to the reason why started this post is that I got reminded about my Foxpro experiences after reading this blog posting by Drew Speedie. Drew has written his comments about a recent interview by Anders Hejlsberg (The Father of C#) where Anders talked about his aim of bringing FoxPro Data handling capabilities to the next version of Visual Studio called “Orcas”.
Reading this post I couldn’t help recollecting my views of FoxPro and xBase. For many years, especially during the days, I was programming and then designing Windows Client/Server Applications – I always wondered why it was not as easy doing common DB tasks in Visual Basic as it was in good ‘ol xBase. For example, even FoxBase+ had very powerful input controls out of the box through its Picture clause, which allowed fine control over what users can type – whether it be a phone number, a numeric value or text (today we call this mask edit controls). Another example could be that in FoxPro/Clipper days we had the ever-powerful Browse Command which allowed rich data editing capabilities that will envy today’s sophisticated Data Edit controls. In CA-Clipper 5.x with its TBrowse Class (Am I not good for remembering all this after so many years), you got absolute control over how it appears on screen and behaviour. You could wire up hundreds of events in TBrowse to Code-Blocks – which were flexible and powerful Macro’s that get compiled during runtime and can do almost everything that was possible in design time coding.
Over the last two decades VB, C# and Java have evolved and made programming easy and approachable to millions of developers. They have certainly realized into applications thousands of dreams, especially in Web and Enterprise scenarios. Building a huge multi-user, multi-location application with FoxPro/Clipper was unimaginable, but today anyone can build that with reasonable effort using say Visual Basic and SQL Server or Java and MySQL. My only complaint is that FoxPro and other xBase languages understood and identified themselves with underlying data much better than today’s programming languages – be it VB or C# or Java. This could be because of the fact that xBase languages had the underlying data engine as part of them. They were a combo of a programming language + Database Engine (in today’s parlance) + Runtime. Because of their close ties with database engines, they had some really useful features/commands that simplified presenting/managing/manipulating data. Identifying and bringing back these into today’s mainstream programming languages like C# and VB.NET, will certainly go a long way in aiding developers.
@babu, yes I do. I have sent you his email in a direct email to you.
Do you know where abouts of Shiv of Sysreader