Clipper and dBase applications on modern Windows: run, recompile or replace

Clipper and dBase were the tools of choice for business software in the late 1980s and early 1990s. Accounts, stock, job cards, membership lists, hire systems and all kinds of trade-specific packages were written with them, and a surprising number are still in use, usually running on an old PC that nobody is allowed to touch.

They share a family resemblance with FoxPro. All three belong to what developers call the xBase family, and all store their data in DBF files. So many of the same problems and solutions apply.

Why they stop working

Clipper and dBase applications from this era are DOS programs, and 64-bit Windows can’t run DOS programs at all. Windows 11 only comes in 64-bit, so when the old PC finally dies, the application appears to die with it.

It usually hasn’t. The program and its data are fine; it just needs somewhere to run.

Option 1: run it in an emulator

The quickest fix is a DOS emulator. DOSBox is the best known, but it was designed for games and isn’t safe for multi-user business systems where several people share data files, because it doesn’t handle file locking the way a business system needs.

vDos was built for business DOS applications. It handles shared files and printing to modern Windows printers far better, and it’s usually the right choice for keeping a Clipper or dBase system going. Our guide to running FoxPro on Windows 10 and 11 covers the same approach in more detail.

This needs no changes to the application, which makes it ideal as a bridge. But it’s another layer of compatibility software on top of an unsupported system.

Option 2: recompile it with Harbour

This is the option most people don’t know exists. Harbour is an open-source compiler that is largely compatible with Clipper. If you have the source code, a Clipper application can often be recompiled with Harbour into a native 32-bit or 64-bit Windows program that runs without any emulator, reads the same DBF files, and looks and behaves much as it always has.

It’s rarely completely effortless. Third-party libraries used by the original may need replacing, printing usually needs rework, and some low-level tricks from the DOS era won’t carry across. But for a well-written application it can be a fast, low-cost way to buy years of life, and it gives you modern code that can be extended, connected to other systems or moved on later.

Commercial alternatives in the same family exist too, such as Xbase++, which markets itself as a successor to Clipper.

dBase applications are more varied. Some can be brought across in a similar way; others are better rebuilt.

Option 3: replace it

If the application does something fairly standard, a modern platform such as Odoo may cover most of it, with your history migrated across. If it does something specific to your business, a modern web application built around the same processes is often the better long-term answer, and the old application itself is the best specification you’ll ever have.

Your data comes first

Whatever you choose, get a clean, complete copy of your data before anything else. DBF files carry traps around memo fields, deleted records and character sets that can quietly corrupt an export, and pound signs are usually the first casualty. Our guide to getting your data out of FoxPro, dBase and DBF files explains what to watch for.

If you don’t have the source code

Without the source, recompiling isn’t possible, but emulation still works, the data can still be rescued, and the running application can be documented screen by screen as the basis for a replacement.

Where to start

A Health Check will establish what you have, whether the source code exists and is usable, and what each route would cost.