Brilliants Computer Centre, Jaipur, 1995. I am sitting in front of a beige 286 machine with an amber monochrome monitor, the air thick with the hum of a dozen identical PCs and the particular brand of sweat that comes from thirty people sharing a room with no air conditioning in Rajasthan. The keyboard is mechanical and heavy — the kind where every keystroke announces itself to the room. I am sixteen years old and I am writing Clipper code.
I type DO MAIN at the DOS prompt and press Enter. The screen clears. Then, character by character, a box draws itself — top-left corner first, then the horizontal line racing across the top, then the right corner dropping down, the sides descending in unison, and finally the bottom sealing itself shut. Inside the box, a menu appears. Below it, a shadow — two characters wide, one character tall — painted in dark gray to give the illusion of depth. On a flat, text-only screen, my program looks like it has windows. It looks, to my sixteen-year-old eyes, like magic.
I did not know it at the time, but I was learning to code in a language that was powering business software on every continent. A language that would teach me more about building practical things with limited resources than any university course ever would. A language that, by the time I understood what it had given me, was already disappearing.
This is about Clipper. The language that built the world’s databases.
What Clipper Was
To understand Clipper, you have to understand the problem it solved.
In the early 1980s, the most popular database software on personal computers was dBASE, made by Ashton-Tate. dBASE was powerful — it let you create databases, write queries, build reports, and even create simple applications using its own programming language. But dBASE was an interpreter. Your programs could only run inside the dBASE environment. You could not ship a standalone application to a client. You could not give someone a program without also giving them a copy of dBASE. For a developer trying to build commercial software, this was a dealbreaker.
In 1984, two men — Barry ReBell and Brian Russell — founded Nantucket Corporation to solve this problem. The legend, which may or may not be true but which I choose to believe, is that they got the idea at a seafood restaurant in Malibu. A picture of a clipper ship on a napkin. The restaurant was called Nantucket Lighthouse. And so Nantucket’s Clipper was born — a compiler that could take dBASE-compatible source code and turn it into a standalone .EXE file that ran on any DOS machine, no runtime required.
The first version shipped in 1985. By the time Clipper Summer ‘87 arrived — confusingly named, since it actually shipped after Christmas 1987 — it had become one of the most popular development tools in the world.
The reason was simple. With Clipper, a developer could write a complete business application — accounting, inventory, payroll, point of sale, banking — compile it into a single executable, copy it onto a floppy disk, and hand it to a client. The client did not need to install anything else. They did not need to understand anything about databases or programming. They just typed a filename at the DOS prompt and the application ran.
For small and medium businesses around the world, this was transformative. For developers, it was freedom.
How You Built an Executable from Nothing
The Clipper build process was a pipeline, and understanding it felt like understanding how a factory works — raw materials in one end, a finished product out the other.
You wrote your source code in .PRG files. These were plain text files containing the Clipper language — a superset of dBASE that added local variables, code blocks, arrays, and a preprocessor with user-definable commands. You ran the Clipper compiler (CLIPPER.EXE), which read your .PRG files and produced .OBJ (object) files. Then you ran a linker, which combined your .OBJ files with the Clipper standard libraries to produce the final .EXE.
What most people did not know — what I certainly did not know at sixteen — was that the Clipper compiler did not produce native machine code. It produced p-code: pseudocode that was interpreted at runtime by a virtual machine baked into the Clipper libraries. The .OBJ wrapper was partly a technical decision and partly marketing genius. It meant that Clipper object files were compatible with standard DOS linkers and, more importantly, with object files produced by C compilers and assemblers.
This was the real power move. You could write most of your application in Clipper — fast to develop, easy to maintain — and then write the performance-critical parts in C or assembly language. The C functions compiled with Microsoft C 5.1 into .OBJ files. The assembly routines assembled with MASM or Turbo Assembler (TASM) into .OBJ files. And the linker — Blinker, ExoSpace, or the bundled RTLINK — stitched everything together into one executable.
You wrote the application logic in Clipper. You wrote the fast parts in C. You wrote the fastest parts in assembly. And the linker made them all into one program.
The linker was more important than most people appreciated. DOS had a hard limit of 640 kilobytes of conventional memory. A serious Clipper application could easily exceed that. So the linkers implemented overlay systems — dividing the executable into segments that were swapped in and out of memory on demand. Blinker, the most popular third-party linker, allocated an overlay pool at startup. A larger pool meant fewer disk reloads and faster execution. ExoSpace went further, using protected mode to break the 640KB barrier entirely, accessing extended memory above one megabyte.
Getting the linker configuration right was an art form. Too small an overlay pool and your application crawled. Too large and you ran out of memory for data. The configuration file for Blinker — specifying which modules to overlay, how much memory to reserve, which libraries to include — was often as carefully tuned as the application code itself.
Drawing Windows with Characters
If the compilation pipeline was the engine of a Clipper application, the screen was its face. And the screen was, by modern standards, absurdly limited: 80 columns, 25 rows, 16 colors. Two thousand characters. That was your entire canvas.
And yet, within those constraints, Clipper developers built interfaces of remarkable sophistication.
The fundamental tool was the @ command. @ 10, 20 SAY "Name:" GET cName placed the word “Name:” at row 10, column 20 of the screen, and created an editable input field next to it bound to the variable cName. A READ command activated all pending input fields for user interaction. The PICTURE clause formatted the input — "999.99" for a number with two decimals, "@!" to force uppercase. The COLOR clause controlled the display colors: "BG+/B" for bright cyan on blue.
This was how you built forms. Character by character, row by row, placing every label and every input field at exact coordinates. There was no drag-and-drop. There was no layout engine. There was you, a text editor, and a mental map of an 80x25 grid.
But the real art was in the boxes.
DISPBOX() drew rectangles on screen using the extended ASCII characters from IBM Code Page 437 — the box-drawing characters that anyone who used a DOS computer will recognize instantly. ╔ for the top-left corner. ═ for the horizontal line. ╗ for the top-right. ║ for the vertical sides. ╚ and ╝ for the bottom corners. You specified eight border characters clockwise from the upper-left, plus an optional ninth character to fill the interior.
A single-line box. A double-line box. A box with single-line top and double-line sides. By combining different border characters, you could create visual hierarchies — an outer window with thick double borders containing inner panels with thin single borders. It looked, squint a little and use your imagination, like a graphical user interface.
Eighty columns. Twenty-five rows. Sixteen colors. Two thousand characters. And within those constraints, an entire generation of developers built business software that ran the world.
And then there were the shadows. Libraries like SuperLib provided shadow functions that drew a dark gray rectangle offset from the box by one or two characters, creating the illusion that the box was floating above the screen. The shadow was not just decoration — it was a depth cue that told the user which window was on top.
The trick that made pop-up windows work was SAVESCREEN() and RESTSCREEN(). Before drawing a window, you saved the rectangular region of the screen beneath it — both the characters and their color attributes — into a string variable. When the window was dismissed, you restored the saved region. The underlying screen reappeared instantly, as if the window had never been there. Stack multiple save-and-restore operations and you had a window system — pop-up menus, dialog boxes, help screens, all layered on top of each other.
Some developers took this further. SuperLib offered animated transitions for restoring screens — FADEAWAY(), SS_HBLINDS() (horizontal blinds), SS_WIPEV() (wipe from top), SS_SLIDELEFT(), SS_FALL(). Your window did not just disappear. It dissolved, or slid away, or fell off the screen. In text mode. On a 286.
I realize, writing this now, that this sounds primitive. But there was something deeply satisfying about building an interface within such tight constraints. You had to think about every character. Every color choice mattered. Every pixel — well, every character cell — was a conscious decision. The limitations forced a kind of design discipline that I think many modern developers would benefit from.
The Ecosystem
No language succeeds alone, and Clipper’s ecosystem was extraordinary — perhaps the most vibrant third-party library culture of any programming language before the internet made open-source distribution trivial.
The Nanforum Toolkit was a community-driven function library born on CompuServe’s Nantucket Forum in late 1990. Nearly 150 functions in its first release, contributed by third-party developers, Nantucket employees, and community members. It was deliberately designed not to compete with commercial products but to fill gaps in Clipper’s standard library. By 1992, it had been downloaded over 2,100 times on CompuServe — a number that sounds quaint now but was significant when distribution meant dialing into a BBS at 2400 baud.
The commercial libraries were where the real power lived. Clipper Tools (later CA-Tools) added hundreds of functions. Funcky extended the language further. The SIx Driver — the SuccessWare Index Driver — was the first Replaceable Database Driver for Clipper, bringing FoxPro-compatible tables and indexes to Clipper developers. It was so good that Computer Associates licensed a subset and bundled it with Clipper 5.2. And FiveWin, perhaps the most important library of all, eventually let Clipper developers create actual Windows GUI applications while still writing in the Clipper language.
The RDD (Replaceable Database Driver) architecture, introduced in Clipper 5.0, was ahead of its time. It made applications data-format independent. Your code talked to an abstract database interface; the RDD translated those calls into operations on the underlying file format. DBFNTX for Clipper’s native .NTX indexes. DBFCDX for FoxPro-compatible compound indexes. Third-party RDDs for Paradox tables, SQL databases, and more. Swap the driver, keep the code. It was, in principle, exactly what ODBC and modern ORMs do today.
The instinct I developed in those years — thinking in terms of structured data, building tools to process and transform it, designing systems that could adapt to different backends — has never left me. When I built a 10,000-book digital library with a Python CLI, REST API, and editorial frontend, or when I built a family recipe system with ingestion pipelines from YouTube and Apple Notes, I was doing the same thing I had learned to do in Clipper: take messy real-world data, give it structure, and build something useful on top.
The World Ran on Clipper
Between 1985 and the mid-1990s, Clipper applications powered an astonishing amount of the world’s business software. Accounting systems. Inventory management. Point-of-sale terminals. Banking software — savings accounts, current accounts, fixed deposits, loan processing, daybooks. Insurance claims. Hospital records. Government databases.
The adoption was global, but it was especially deep in the developing world. In India, where I learned to program, Clipper was everywhere. Every midsized business that needed software — and could not afford a mainframe or a team of COBOL programmers — hired a Clipper developer to build something custom. The entire first generation of Indian IT professionals, the generation that would go on to build the outsourcing industry, cut their teeth on Clipper and FoxBase and dBASE.
In Brazil, the Clipper community was enormous — among the largest in the world. Programming courses in Clipper were a standard entry point into IT careers. In Southeast Asia, in Eastern Europe, in Africa, the pattern repeated: wherever businesses needed affordable, customizable database software, Clipper was there.
(Quick aside: I find it remarkable that so few people in the technology industry today know about Clipper. It was, for a period of roughly a decade, one of the most widely used development tools on Earth. Millions of applications. Hundreds of thousands of developers. And yet it has largely vanished from the collective memory of the industry. The tech world has a very short memory for anything that is not currently making someone a billion dollars.)
What made Clipper so successful in these markets was the economics. A developer with a PC, a copy of Clipper, and enough skill could build a complete business application in weeks. The cost to the client was a fraction of what mainframe development would have required. The applications were fast, reliable, and — because they compiled to standalone executables — easy to deploy. No installation headaches. No dependency management. No runtime environment to configure. Just an .EXE file and a DOS prompt.
The Windows Cliff
In 1992, Computer Associates acquired Nantucket Corporation for $190 million. Clipper became CA-Clipper. And then, slowly, everything fell apart.
The problem was Windows. Microsoft Windows 3.1, and later Windows 95, were transforming personal computing from a text-mode, single-tasking environment into a graphical, multitasking one. Clipper was a DOS tool, and DOS was dying.
CA’s answer was CA-Visual Objects — a new Windows development environment that was supposed to be the natural upgrade path for Clipper developers. It was not. Visual Objects was too different from Clipper. The syntax had changed. The paradigm had changed. The reliability was questionable. Most Clipper developers tried it, struggled with it, and abandoned it.
The migration scattered the community. Some developers moved to Visual Basic. Others went to Delphi, which offered a similar rapid-application-development feel. Some chose Microsoft Access for simpler database applications, or PowerBuilder for client-server systems. A dedicated minority stayed on Clipper 5.2e — widely considered the most stable release ever — and used FiveWin to put Windows GUI faces on their Clipper code.
Many developers, myself included, leapfrogged the entire client-server era. We went from DOS straight to the web. From @ 10, 20 SAY to HTML forms. From DBFNTX to MySQL. From distributing floppy disks to deploying on servers. The intermediate step — Windows desktop development with Visual Basic or Delphi or Visual Objects — was a step that many of us never took. We skipped it entirely, the same way India’s telecom sector skipped landlines and went straight to mobile.
I wrote about my own career arc — from running a web design shop in the early 2000s to journalism to digital marketing to streaming — and I realize now that the thread connecting all of it was the thing I learned sitting at that 286 in Jaipur: how to take a blank screen and make it do something useful. The tools changed. The screens got bigger and more colorful. The databases moved to the cloud. But the fundamental act — understanding a problem, structuring data to solve it, building an interface for a human to interact with it — has not changed at all.
The Ghost in the Machine
Clipper is not dead. Not exactly.
Harbour, an open-source project started in 1999, is a cross-platform compiler that is 100% backward compatible with Clipper 5.x. It compiles on Windows, Linux, macOS, iOS, Android, and more. It supports modern backends — MySQL, PostgreSQL, SQLite, OpenSSL, cURL — and has GUI frameworks for building contemporary applications. xHarbour, a fork, offers similar compatibility. Both are actively maintained.
There are developers, right now, in 2026, taking Clipper code that was written in the late 1980s and compiling it with Harbour for modern operating systems. Applications that have been running for thirty-five years, still processing data, still serving businesses, now running on hardware that is millions of times more powerful than the machines they were written for.
I find that extraordinary. Not because the code is elegant or the technology is cutting-edge — it is neither — but because it speaks to something about the durability of well-built tools. A Clipper application written in 1990 to manage inventory for a small business in Jaipur or São Paulo or Jakarta was not trying to disrupt anything. It was trying to solve a problem. And if the problem still exists, and the solution still works, then the tool still has value. Thirty-five years later.
Every time I rebuild a personal site — choosing Jekyll over a heavyweight framework, preferring static files over a CMS, reaching for simplicity over cleverness — I am, in some way, still that sixteen-year-old in Jaipur. Still looking for the most direct path between a problem and a solution. Still finding satisfaction in constraints. Still drawing boxes on a screen and making them do something useful.
The tools change. The screens get better. The databases move to the cloud. But the instinct to build — to sit at a blank screen and make it come alive — that does not change.
That is what Clipper taught me. And I suspect, if you are reading this and you ever wrote a line of xBase code, it taught you the same thing.
Clipper was created by Nantucket Corporation (1984) and later acquired by Computer Associates (1992). The versions referenced in this essay include Summer ‘87, 5.0, 5.2e, and 5.3. The open-source successors Harbour and xHarbour continue active development. The Nanforum Toolkit, CompuServe forums, and third-party libraries like Blinker, SIx Driver, FiveWin, and SuperLib were central to the Clipper ecosystem.