Harbour in 2026: the first stable release in 15 years, and what it means for your Clipper app

In July 2026, the Harbour project shipped version 3.2.0 — its first stable release since 3.0.0 in 2011. Fifteen years between stable tags is the kind of fact that sounds like a punchline about dead software. It is the opposite: the 3.2 branch has been alive, maintained and quietly running production systems that whole time — as an eternal “development snapshot”. What changed in July is not the code. It is the label, and labels matter more than engineers like to admit.

If your company still runs a Clipper-era application, this release is the best news your legacy stack has had in a decade. Here is why — and where the enthusiasm should stop.

What Harbour is, in one paragraph

Harbour is the open-source successor of the Clipper language: a compiler that takes the same PRG code Clipper took, compiles it to C, and produces native executables for modern platforms — 32- and 64-bit Windows, Linux, and more. It reads and writes the same DBF tables and NTX/CDX indexes through replaceable database drivers, so a ported application works on the same live data files as the original EXE. The classic Clipper extension libraries have Harbour counterparts, the build tool (hbmk2) turns the old make ritual into a one-line command, and the language has grown modern conveniences (classes, hash tables, multithreading) without abandoning dialect compatibility. Commercial forks (xHarbour and friends) exist alongside it; Harbour is the community mainline.

Why a version label matters to your business

For engineers, “we’ve run the dev snapshot in production for years” is normal. For everyone who signs things, it is a problem:

• Procurement and audits. “Our platform is a nightly build of an open-source project” reads very differently from “our platform is Harbour 3.2.0, released 2026”. Auditors, insurers and customers’ vendor-security questionnaires want a version, a date, a tag.
• Reproducible builds. A stable tag means you can pin the exact compiler, archive it, and rebuild the same binary in five years — the foundation of every serious containment plan for a legacy system.
• Succession. The developer who eventually inherits your system can download the same documented release, not “the snapshot from the USB stick Misha left”.
• Signal. A project that cuts a stable release after 15 years is telling you it intends to be here for the next 15. For a language whose commercial vendor died in the 1990s, that continuity signal is the entire value proposition.

What a Harbour port actually looks like

We have ported a production Clipper-family utility — a decades-old codebase over live DBF/CDX data — to Harbour, building both 32- and 64-bit native Windows executables and verifying them against the same server-hosted tables the original used. The honest experience, in proportions:

• Most of the code just recompiles. Core xBase logic — database access, index expressions, business rules, SET RELATION chains — carries over untouched. This is what makes a port a containment project rather than a rewrite.
• The work concentrates at the edges. Screen handling beyond plain @SAY/GET, printer tricks that assumed an LPT port, inline C or assembler, and third-party .LIB files are where the effort lives. Most classic libraries have Harbour equivalents; truly exotic ones need small shims.
• The build system is a gift. hbmk2 app.prg replaces the RTLINK incantations, and the same project file builds x86 and x64 from one source tree.
• 64-bit is not vanity. It means no 16-bit emulation anywhere in the chain, first-class behavior on current Windows, and — where the data layer is client/server (for example an Advantage-backed system) — access to modern 64-bit client stacks, which in our benchmarking were meaningfully faster than their 32-bit siblings.

A port of this kind is measured in weeks, not quarters — a fraction of any migration — and at the end the application is the same application: same keystrokes, same data files, same muscle memory on the plant floor. That sameness is precisely the point. Behavior preserved by recompilation is behavior you do not have to reverse-engineer later; the ported binary becomes a scriptable reference implementation for the parity testing that a future real migration will need.

What Harbour does not fix

Containment is a strategy, not a destination, and it is worth being blunt about the limits:

• It is still xBase. The pool of developers who can extend the system does not grow because the compiler got younger.
• It is still DBF (unless you move the data layer to a server backend) — the 2 GB per-table ceiling, the shared-file locking model and the index-corruption folklore come along for the ride.
• The UI stays the UI. Your veterans will love that; your new hires and your customers will not. Web access, integrations, audit trails — none of that appears by recompiling.
• The clock keeps ticking. A Harbour port removes the platform emergency (16-bit executables, dying hardware, unsupported OSes). The organizational emergency — one person who understands the system, zero tests, undocumented rules — is untouched.

That is why we treat Harbour as step one of two: contain now, on your timeline, cheaply — then decide between keeping the contained system, wrapping it, or a parity-tested migration, with the pressure off. The full decision framework is in rewrite vs convert vs wrap.

Is a port right for your system?

Signals that say yes:

• The application still runs the business, and runs it well — the pain is the platform, not the logic.
• You are one hardware failure away from an outage (the last DOS-capable PC, a fragile VM, an emulator nobody dares touch).
• The source code substantially exists. (Partial loss is survivable; total loss changes the conversation.)
• A full migration is desirable eventually but not fundable now.

Signals that say skip straight to migration: the business has outgrown the workflows themselves, the data already needs to live in SQL for integration reasons, or compliance requirements (audit trails, access control, encryption) can never be met by a shared-file database no matter what compiles it.

With 3.2.0 stable, the port option finally comes with a version number your CFO can put in a risk register. For a 30-year-old system, that is not a small thing.

Our Clipper/xBase practice runs exactly this two-step: Harbour containment measured in weeks, then — if and when you choose — a parity-tested migration. The fixed-price assessment tells you which step your system actually needs first.