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
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
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
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 :
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 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
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
* 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.
of VFP, FPW (foxPro for Windows) FPD (FoxPRo for DOS) and foxbase is all the
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
Proceso C. Mejia V