This book provides a much needed tutorial for the xBaseJ project. Even if you know little about Java and nothing about XBASE data storage you will be banging out applications like a pro by the end of this tutorial.
The book is written in the same informative and entertaining style as the rest of "The Minimum You Need to Know" book series.
Roland Hughes is the president of Logikal Solutions, a business applications consulting firm specializing in VMS platforms. Hughes serves as a lead consultant with over two decades of experience using computers and operating systems originally created by Digital Equipment Corporation (now owned by Hewlett-Packard).
Why This Book?
I asked myself that same question every day while I was writing it. Why am I going to write a book much like my other books and give it away for free? The simple answer is that I had to do a lot of the research anyway. If I have to do that much research, then I should put out a book. Given the narrowness of the market and the propensity for people in that market to believe all software developers work for free, the book would physically sell about two copies if I had it printed. (Less than 1/10th of 1% of all Linux users actually pay for any software or technology book they use.)
What started me down this path was a simple thing. In order to make a Web site really work, a family member needed to be able to calculate the 100 mile trucking rate for the commodity being sold. The commercial Web site had a really cool feature where it would automatically sort all bids within 300 miles based upon the perbushel profit once the transportation costs were taken out. The person already had a printed list of the trucking rates, so how difficult could it be?
Some questions should never be asked in life. “Wha t could go wrong?” and “H ow difficult could it be?” are two which fall into that category. When you ask questions like that, you tend to get answers you were unprepared to hear.
In my early DOS days, I would have sat down and begun coding up a C program using Greenleaf DataWindows and the Greenleaf Database library. Of course, back then, we didn't have the Internet, so I would have had to use the Greenleaf CommLib to dial out to some BBS to get the DOE (Department of Energy) national average fuel price.
During later DOS days, but before Microsoft wrote a taskswitching GUI that sat on top of DOS and that was started by typing WIN at the C:> prompt which they had the audacity to call “The Windows Operating System,” I would have reached for a C/C++ code generator like ProC from Vestronix (later ProC Corp.) or DataBoss from Kedwell Software. Neither program did communications, but both could be used to quickly lay out xBASE databases, generating entry/maintenance screens, menus, and reports in a matter of minutes. You could create an entire application that used just a few files for distribution, all of which could be copied into a single directory, and the user would be happy.Once Windows came out, things got ugly. I did a lot of OS/2 work, even though not many companies or people used it. The problem with OS/2 was that IBM had Microsoft develop it and Microsoft was intent on ensuring that OS/2 would never be a threat to Windows. (Windows wasn't even an actual operating system until many years after OS/2 came out.) Once IBM had the bulk of the Microsoft code removed from it, OS/2 became an incredibly stable platform which managed memory well. IBM didn't manage it well, saddling developers with expensive device driver development tools that would only work with an increasingly hard to find version of Microsoft C.
Most of us did crossplatform development in those days. I used Watcom C/C++ for DOS, Windows, and OS/2 development (now OpenWatcom as the project is OpenSource). It was easy when you used the Zinc Application Framework for your GUI. There were a ton of crossplatform indexed file libraries. Greenleaf supported a lot of compilers and platforms with its Database library for xBASE files. Of course, there were a lot of shareware and commercial Btree type indexed file systems out there. These had the advantage of locking the user into your services. These had the disadvantage of locking the user into your services. They weren't widely supported by “common tools” like spreadsheets and word processors. The one I remember using the most was CIndex/II from Trio Systems LLC. As I recall it was written generically enough that it actually worked on DOS, MAC, Windows, and OS/2. Of course, that was during the brief period in life when the Metrowerks CodeWarrior toolset supported the MAC.
In short, from the 80s through the end of the 90s we always had some way of creating a standalone application with its own indexed local data storage that didn't require lots of other things to be installed. When Windows started going down the path of “needing lots of other stuff” was when you started seeing companies selling software to do nothing other than develop installation programs for Windows.
As an application developer who is quite long in the tooth, I don't want to link with DLLs, shared libraries, installed images, or any other thing which is expected to be installed on the target platform. I have heard every justification for it known to man. I was there and listened to people slam my C program because their Visual Basic (VB) application took only 8K and “looked slicker” than my application which consumed an entire floppy. I was also there to watch production come to a screeching halt when a new version of the VB runtime got installed to support some other “mission critical app” only to find all previous apps were now incompatible.(The machine running my C program which took a whole floppy continued to keep the business it supported running while much screaming and fingerpointing was going on all around it.)