Site hosted by Build your free website today!


    Fox Software was a small company started by Dr. Dave Fulton and a bunch of his graduate students in Ohio, who were doing custom computer consulting on the side, I think. They figured they could write a better dBASE than dBASE. And they convinced other people they had done it, by going to a dBASE convention and asking people to run their own PRGs and applications under the FoxBase environment, where the code immediately ran faster. No code changes, just better technology underlying the same Xbase language features.

     They improved FoxBase, but mostly kept it as a dBASE clone, until somebody convinced Dr. Dave to put out a Mac version. I think he wasn't very enthusiastic at first. I think he did it to prove that it was a "trivial exercise" .

     But the Mac environment intrigued him. By the time he was finished with FoxBase Mac, which probably took longer than he'd expected, he'd seen the advantages of the Mac UI, and he'd resolved to create a new FoxBase -- which became FoxPro 1.0 -- which would have a lot of the features of the Mac interface but would not be a GUI environment.

     If you've wondered why Fox had a Puzzle and other DA's, or why the menu bar in Fox DOS was System File Edit, now you know: these are Mac conventions < s >. FoxPro DOS was born from FoxBase Mac -- not its language, but the assumptions of how it should work and look. To Dr. Dave and the Fox team, whether you expressed those assumptions in graphics or characters was irrelevant.

     Unlike dBASE III and FoxBase, windows weren't an afterthought in FoxPro 1; they were part of how you worked, just as they were on the Mac. Other things stayed just as they were in FoxBase DOS; FoxPro 1 kept Fox's deserved reputation for running quickly. Although it took more resources than FoxBase, its improved ability to produce a finished inteface deserved those resources, and its data handling was still without peer.

     But the Fox team knew that this wasn't the whole story. People were using tools such as templates and screen painters. FoxCode/FoxView were included with FoxPro 1 but never really caught on; I used something called SCRIMMAGE, written by Russell Freeland, which was a generic Xbase tool. But these tools needed tighter integration with the language and the Fox style of working.

     We already had a Report Writer -- pretty similar to the one available in dBASE -- so that "positioning" in output was less of an obsession than it had been, in hand-coded reports. FoxPro 2 offered additional tools in which you painted Screens and Menus, and out of which code was generated for you, again to eliminate some details of positioning and put the focus on design. The Project Manager offered you a chance to focus on application design -- the way your files were supposed to work together -- rather than the mechanics of compiling and file management.

     At the same time, SQL and the idea of optimized data access through new index types (Rushmore optimization) entered the language. This was how Fox 2 kept breaking new ground in the speed/efficiency dept.

     There were many heroes in the original team, including Amy Fulton, Dr. Dave's wife and the original architect of the RQBE (the visual tool that was intended to do for the SQL additions to the language what the other tools did for Screens, Reports, Projects and Menus) and Dave McClanahan, who did a lot of the original SQL work, and Walt Kennamer, who wrote FoxDoc as Snap! before he joined Fox as COO. I'd have to mention Janet Walker, who guided just about every facet of the development, from what I can reckon.

     Outside Fox Software, people like Tom Rettig and Alan Schwartz (although there are actually no people *like* Tom Rettig and Alan Schwartz < s >) helped grow the community. The two were interfaced by a thriving set of CompuServe Fox Forums, hosted by the company but enlivened by the efforts of many thousands of committed Fox developers, who built additional tools and stretched every ounce of capacity out of the Fox language and data format. Both "in" and "out" of the community was Glenn Hart, who served as a consultant to the company and spearheaded the community effort on CompuServe.

     Glenn's sudden passing was a shock to us all, and serves me as a sort of watershed date in the history of Fox. A few months later, the Fox-MS merger was announced, at a "breakfast press meeting" on the first morning of dbExpo. Dr. Dave and Bill G made the announcement jointly. I remember thinking that it was difficult for any more effective underminding of Philippe Kahn's keynote speech to have been planned, by anybody < s >.

     FoxPro 2.5 DOS and Windows were under development at the time. I believe that the development team (most of whom were going to Redmond) had a committment to get these products ready for release before the final merger. I'm afraid that the timing of RTM for these products had something to do with people wanting to be settled into their new Seattle digs before their children started school .

     After FoxBase Plus for DOS, Dr. Dave decided to port to the Macintosh. At first, he didn't think much of the Mac, it was just a "challenge" that somebody proposed and he wanted to overcome, I think.

     However, when he looked closely at the Mac's philosophy, and how this was expressed in its event-handling and visual interfaces, he grew much more interested.

     Dr. Dave has said, more than once, that it was the Mac's features and abilities that stimulated him and his team to create the FoxPro 1 interface (both development environment and runtime capabilities of FoxPro 1 applications).

     Although FoxPro 1 was character-based it did a pretty good job of having the same windowing look and feel, and all the functionality, of what we like about all the GUI interfaces today.

     He figured out "what made the Mac a Mac", in other words, and he applied that set of principles to a completely different problem. I think this was a stroke of sheer genius on their part.

    Effectively being a much faster clone of dBase III, FoxBase contained the minimum necessary to define the tables of a database and a programming language which contained all necessary to write applications very quickly.

     A database consisted of several tables and their indexes. The association of tables and their indexes must explicitly be done using commands.

     The programming language used is completely procedural. It contains statements to create menu's, open and close tables, filter tables (querying), insert, update and delete records, view records through screens and a browse statement. Defining all these things in a program is quite straightforward. Records are manipulated as program variables. All data is stored in ASCII format.

     One special feature which originated in dBase, are 'macro's'. These macro's are text strings, which could be compiled and interpreted at run-time. This was a necessary feature, because most statements took string arguments without quotes, e.g. OPEN MY_TABLE. If you wanted to define a statement with a parameter, you could not directly refer to a variable. Trying to execute OPEN ARG_TABLE, the program would search for the file 'ARG_TABL'. To circumvent this problem you need to code the following :

         ARG_TABLE = "MY_TABLE"




    Clipper originated as a dBase compiler, but added soon after powerful extensions to the language. I have also worked with the Summer '87 and the 5.0 version. At the database level, nothing changed very much from FoxBase, but at the user interface level and the programming level, several advanced features offered faster development turn-around times and advanced user interfacing. The macro feature was still available, but Clipper expanded it through code blocks. In the original implementation, a macro needed to be evaluated every time it was used. In cases where macro's where used to filter data, this amounted to waste of computing time. The introduction of the code block made it possible to compile a macro just once and then use the compiled version.

     Other features where the introduction of some object-oriented classes for user interfacing, a powerful multi-dimensional array type, declarations for static and local variables and a plethora of functions to manipulate arrays and tables. The flipside of all this was that learning to effectively use the language took some more time. I have two books about Clipper 5.0 and they are quite large.

FoxPro 2.0

    FoxPro was the successor of FoxBase. It added GUI-features to the text-interface, making it possible to work with overlapping windows. FoxPro 2.0 also added embedded SQL statements. It was only a subset with SELECT, INSERT, UPDATE and DELETE, but this offered already a substantial advantage over the standard query statements. It also offered a better integration between tables and their indexes, and one of the most powerful query optimizers ever developed. They also provided some development tools, of which the most important where the screen development and the source documentation tools.

     Clipper and FoxPro made it also possible to program for networks and thus enable multi-user database systems.

     Summary of important features

    If I look in retrospect to these systems, what were the important features which made programming more productive ? This reference must be made against postgreSQL and the available libraries for interfacing to the back-end. It must also be made from the point of the production programmer, who must be able to write applications without being bothered by irrelevant details.

    * Field names translate to native variable names

       Defining a field name for a table makes it available under the same name to the program which can then use it as an ordinary, native variable.

    *   Uniform memory allocation system

       The xBase systems have a dynamic memory allocation scheme, which is completely handled by the runtime library. COBOL is fully statically allocated. In none of these languages the programmer needs to be concerned with tracking allocated memory.

    *   Direct update through the current record

       The manipulated record is available to update the table through one or another UPDATE statement.

    *   Database statements have the same format as the application language


      When programming in xBase, the statements to extract and manipulate data from the database tables formed an integral part of the procedure language.

      In COBOL, the statements where embedded and processed by a preprocessor. The syntax of the available statements was made to resemble COBOL syntax, with its strong and weak points.

    *   Simple definition and usage of screens

       In xBase, there are simple yet powerful statements available for defining screens. Screens are called through only one or two statements.

    In WANG PACE, screens can only be defined through the screen editor. There are three statements available : one to use menu's, one to process one record in a cursor and an iterative version to process all records in a cursor. Most screen processing is handled through the run-time libraries.


   The concept of VFP, FPW (foxPro for Windows) FPD (FoxPRo for DOS) and foxbase is all the same.

    It is, like the basis formed by xBase, a programming language that is developed, in the case of the fox, by Dr. Fuller, with in mind that it should be possible to handle large amounts of data.

    This, of course, can be achieved in different ways:

    1) Through handling data its own way. At the time the tool was first developed dbf files where very popular.

    Indexfiles and the way the tables and indexes are searched know many techniques. However never described the rushmore technology of Fox is unbeaten.

    2) By implementing other data-centric languages, SQL is the mainstream here. Instead of concentrating on records SQL concentrates on sets of data. Hence the name cursor which stands for "CURrent Set Of Records". (see the uppercase letters)

Proceso C. Mejia V                 

   CS 3-1