Purpose
This comparison places x64base / DotTalk++ Workbench in the broader xBase, DBF, Clipper, FoxPro, and DBF-library ecosystem.
It is not a replacement-claim table. Some systems here are mature commercial products, some are open-source compilers, some are migration platforms, and some are file-access libraries. x64base is different in emphasis: its primary intent is educational and architectural, with practical database/runtime uses developing around that core.
Reading The Table
- Yes means the feature is present or clearly supported.
- Partial means the feature exists in a limited, developing, or scoped form.
- No means it is not a meaningful feature of that system.
- Unknown means we should not claim it without better source proof. It is not a claim that the feature is absent, and it is preferred over a plausible guess. Unknowns are omitted or marked; they are not filled in.
- Not same claim means the project has adjacent capability but not the same architectural goal.
A "Yes" for Harbour or Xbase++ may mean mature application-platform support. A "Yes" for x64base means project/source/runtime evidence exists, but active-beta status still applies unless specifically marked production-ready.
Product / Project Character
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| Primary role | Educational-first open xBase/DBF architecture, self-documenting runtime, workbench family, and 64-bit DBF-style research system | Open xBase compiler/runtime | Open Clipper/xBase compiler/runtime | Commercial Clipper/xBase modernization platform | .NET xBase dialect/compiler | Commercial DBF/database products and utilities | DBF read/write libraries |
| License / business model | Project/open architecture, active beta | Open source | Open source | Commercial | Mixed/open/commercial ecosystem | Commercial | Open source packages |
| C++ codebase | Yes | Mostly C runtime/compiler code, not a C++ OO codebase claim | Mostly C runtime/compiler code, not a C++ OO codebase claim | Closed/commercial | .NET/C# ecosystem | Closed/commercial | Python |
| Compilable application/runtime | Yes | Yes | Yes | Yes | Yes | Yes, product dependent | No, library use |
| Source can be changed | Yes | Yes | Yes | No, product source closed | Partly, depends on component | No | Yes |
| Production maturity | Active beta / educational / research | Mature open-source project | Mature legacy/open-source project | Mature commercial platform | Active .NET migration/compiler ecosystem | Mature commercial/legacy tools | Mature for utility/file tasks |
Storage, Tables, Memos, And Indexes
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| 64-bit DBF-style table architecture | Yes, active DBF_64 lane with wide header/runtime metrics and boundary-canary proof beyond the old 16-bit geometry ceilings | Not same claim | Not same claim | 64-bit Windows platform support, not same DBF_64 claim | Not same claim | No, classic DBF family | No |
| 64-bit memo architecture | Yes, DTX/FPT64 lane with 64-bit object ids and offsets | No/unknown | No/unknown | No/unknown | No/unknown | Classic DBT/FPT | No, classic memo support only |
| 64-bit indexing architecture | Partial: the active CDX/LMDB path carries 64-bit record numbers (RecNo = uint64_t, 8-byte little-endian storage; index-hook and keyed-seek decoders widened, public build 2026-07); classic CNX and legacy .inx are kept 32-bit by design and report their ceiling. Boundary proof past 2^31 is green (unit + sparse-file end-to-end tests) | Classic RDD/index ecosystem | Classic index ecosystem | DBF/NTX/CDX engines | Runtime dependent | Classic indexes/tools | Usually no persistent index support |
| 64-bit record navigation and locking | Yes, in the public build: GO/GOTO/SKIP/RECNO/TOP/BOTTOM/FIRST/LAST/NEXT/PRIOR, the table-buffer change key, and the record-lock API were widened to 64-bit (CURSOR and INDEX_X64 regression-checked), and the classic recno()/recLength()/recCount()/cpr() accessors now return -1 past their 32-bit range instead of saturating. Addressing past 2^31 is proven end-to-end — the engine reads distinct records at recno 2^31+1/+2 off a sparse x64 table | Classic xBase record model | Classic xBase record model | Runtime/DBE dependent | Runtime dependent | Classic | Library/dialect dependent |
| 32-bit/classic DBF support | Yes, MS-DOS/classic lane | Yes | Yes | Yes | Dialect/runtime dependent | Yes | Yes |
| VFP DBF support | Yes, VFP headers/types lane | DBF/RDD dependent | DBF/RDD dependent | Yes | VFP dialect/runtime work | Yes | Yes in selected libraries |
| VFP currency field support | Yes | DBF/RDD dependent | DBF/RDD dependent | Unknown | Runtime dependent | Yes in VFP/dBASE variants | Yes in dbf; read support varies |
| Memo fields | Yes | Yes | Yes | Yes | Runtime dependent | Yes | Yes, library dependent |
| Vectored long table/field names with fallback mangling | Yes, x64 metadata supports up to 256-byte table/field names (ceiling raised from 128 in 2026-07; default 128) with classic 10-byte fallback descriptor tokens | Not same claim | Not same claim | Product dependent | .NET/runtime dependent | Product dependent | No |
| Custom field types | Yes — register-once codec registry (type code + codec + on-disk width + flavor eligibility); the built-in I/B/Y/T binary types use the same path, and a worked custom type ships as a demo | Not same claim | Not same claim | Product/runtime dependent | .NET type system | Product dependent | Conversion hooks only |
Language And Runtime
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| xBase-style command language | Yes | Yes | Yes | Yes | Yes/dialects | Yes | No |
| DotScript / script files | Yes | Harbour scripts/tools | Unknown | Yes/product dependent | Yes/compiler/runtime dependent | Product dependent | Python scripts only |
| Variables | Yes | Yes | Yes | Yes | Yes | Yes | Python variables |
| Conditionals | Yes: IF, ELSE, ENDIF | Yes | Yes | Yes | Yes | Yes | Python |
| Loops | Yes: LOOP, ENDLOOP, WHILE, UNTIL, SCAN, ENDSCAN | Yes | Yes | Yes | Yes | Yes | Python |
| Script nesting | Yes, currently one level | Yes/language dependent | Yes | Yes | Yes | Product dependent | Python |
| Scalar functions | Yes, runtime catalog present; SYSFUNC promotion lane still maturing | Yes | Yes | Yes | Yes | Yes | Python/library functions |
| Object-oriented support | Hybrid C++ object model for DB areas, memos, workspaces, and workbench services | Language-level class/object features exist, but the public implementation is mostly C and should not be described as C++ OO architecture | Language-level class/object features exist, but the public implementation is mostly C and should not be described as C++ OO architecture | Yes, Xbase++ platform/language support | Yes, .NET class/object model | Product dependent; do not generalize classic DBF tools as OO | Python object APIs, not DBF engine OO architecture |
| Compile to native/runtime application | Yes | Yes | Yes | Yes | Yes/.NET | Yes/product dependent | No |
Data Mutation And Safety
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| Record mutation | Yes: REPLACE | Yes | Yes | Yes | Yes | Yes | API assignment/write |
| Calculated mutation | Yes: CALC, CALCWRITE | Yes/language expressions | Yes | Yes | Yes | Product dependent | Python expressions |
| Multi-field mutation | Yes: MULTIREP / replace multi lane | Yes/app code | Yes/app code | Yes/app code | Yes/app code | Product dependent | Python code |
| Buffered table editing | Yes: table buffer, dirty/stale, commit/rollback lifecycle | Varies by RDD/runtime | Varies | Yes/mature product behavior | Runtime/database dependent | Product dependent | Object/write semantics only |
| Dirty/stale state reporting | Yes | Runtime dependent | Runtime dependent | Product dependent | Database dependent | Product dependent | No native DBF engine state |
| Commit/rollback | Partial: table-buffer lifecycle, not full ACID RDBMS claim | Backend dependent | Backend dependent | Product/database dependent | Database dependent | Product dependent | No native DBF transaction engine |
| Record locking | Yes | Yes | Yes | Yes | Runtime/database dependent | Yes/product dependent | Usually limited/no full lock manager |
| Multi-user concurrency | Partial/developing | Mature xBase/RDD dependent | Mature xBase/RDD dependent | Mature commercial | Database dependent | Product dependent | Usually no |
Relational, SQL, And Database Behavior
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| Work areas / DB areas | Yes | Yes | Yes | Yes | Runtime dependent | Yes | No |
| Workspace wrapper over areas | Yes | Not same claim | Not same claim | Product/project dependent | Runtime dependent | Product dependent | No |
| Workspace snapshot to a plain-text file | Yes: .dtschema captures areas, index attachments, tag orders, aliases, and declared relations; one command restores 43 areas + 58 relations | Not same claim | Not same claim | Product/project dependent | Runtime dependent | Product dependent | No |
| Self-locating snapshot (carries its own data roots) | Yes, format v3: a restore resolves against the payload's roots, proven from a deliberately wrong environment | Not same claim | Not same claim | Not same claim | Not same claim | Not same claim | No |
| Session state in the snapshot (cursor positions + selected area) | Yes, format v3: positions restored, then relations refreshed so children re-slave to restored parents | Not same claim | Not same claim | Not same claim | Not same claim | Not same claim | No |
| Workspace stored inside a database table | Yes: WORKSPACE SAVE <name> MEMO writes the snapshot into a memo field of a self-creating catalog, attributed, versioned by supersede, byte-verified on write | Not same claim | Not same claim | Not same claim | Not same claim | Not same claim | No |
| Whole small database carried in one memo field | Yes: MINIDB container carries posture + every table and index byte (94 KB for a 13-table system), oracle-verified as a unit | Not same claim | Not same claim | Not same claim | Not same claim | Not same claim | No |
| Hydrate a stored database into RAM on demand | Yes: from disk or from the memo itself -- 24 files / 92 KB in the 65-95 ms range, census cross-checked, dropped by unmount | Not same claim | Not same claim | Not same claim | Not same claim | Not same claim | No |
| Multiple workspaces simultaneously resident | No -- load is a swap, not co-residency; the naming and residency hazards are measured and registered before any build | Not same claim | Not same claim | Product/project dependent | Runtime dependent | Product dependent | No |
| Relations (navigational model) | Yes: REL, relation tree, relation-aware browse; declared edges followed by traversal | Yes/xBase model | Yes | Yes | Runtime dependent | Yes/product dependent | No native |
SQL SELECT over native DBF tables | Partial: SQLSEL SELECT with WHERE, ORDER BY, LIMIT, COUNT(*), oracle-verified against SQLite; no JOIN or GROUP BY yet | Vendor site lists "Native RDDs, SQL, ODBC" as connectivity features; SQL over local DBF not evidenced there | Unknown | Yes: Universal-SQL runs SELECT/INSERT/UPDATE/DELETE against a local or shared DBF table, per vendor feature list | Dialect model confirmed (a VFP dialect exists); SQL-over-DBF specifics Unknown | Unknown | No |
| Tuple/grid relational view | Yes | App/library dependent | App/library dependent | Product/app dependent | App dependent | Product dependent | No |
| Built-in SQL bridge | Partial: SQL, SQLite, import/export, and DDL bridge lanes | Yes, SQL/ODBC listed | Unknown | Yes, Universal SQL | .NET data access | Yes/product dependent | External Python SQL only |
| Full SQL server/RDBMS | No | No, but can bridge | No, but can bridge | Can bridge to server DBs | Uses .NET DBs | Product dependent | No |
| Referential validation | Partial: relations, rules, validation hooks | App/RDD dependent | App/RDD dependent | Product/database dependent | Database dependent | Product dependent | No native |
| Database triggers | Yes: TRIGGER, RULE, VALIDATE lanes | App/RDD/SQL dependent | App/RDD/SQL dependent | Product/database dependent | Database dependent | Product dependent | No native |
| Constraints / validation | Yes, developing | App/RDD dependent | App/RDD dependent | Yes/product dependent | Database dependent | Product dependent | Python code only |
| DDL | Yes: DDL fetch/validate/create DBF/sidecar lanes, with caveats | Via language/libraries | Via language/libraries | Yes/product dependent | Database dependent | Yes/product dependent | Create/write DBF varies |
Import, Export, And Interchange
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| CSV import | Yes | Possible via libraries/code | Possible via libraries/code | Yes, Universal SQL mentions CSV | .NET libraries | Product/tool dependent | Yes via Python |
| CSV export | Yes | Possible via libraries/code | Possible via libraries/code | Yes | .NET libraries | Product/tool dependent | Yes via Python |
| DBF import/export | Yes | Yes | Yes | Yes | Runtime dependent | Yes | Yes |
| SQL import/export | Yes, scoped bridge | Yes/ODBC/SQL backends | Unknown | Yes | Yes via .NET | Yes/product dependent | Python ecosystem |
| Memo import/export | Yes, developing with known CSV newline caveats | Yes | Yes | Yes | Runtime dependent | Yes | Yes, library dependent |
| Data dictionary / metadata catalogs | Yes, DDICT, META, SelfDoc, manualgen, and website-feed lanes | Documentation/tool dependent | Tool dependent | Product/workbench dependent | Tool dependent | Product dependent | No |
UI, Tools, And Developer Experience
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| CLI interface | Yes | Yes | Yes | Yes | Yes/tooling | Product dependent | Script/API only |
| TUI interface | Yes: Arctic TUI code-name surface inside the ArcticTalk / DotTalk++ Workbench family | Yes | Yes | Yes/text mode | Possible | Legacy/product dependent | No |
| GUI interface | Yes: Parallel GUI/TUI lane with wxWidgets C++ and Python/Tk workbench lanes | Yes, UI backends | Yes, GT/GUI support | Yes, Workbench/GUI/web | .NET GUI possible | Yes | No native GUI |
| User-defined menus/windows/dialogs | Planned UI DSL lane; current workbench menus/windows are supplied by the active frontends | Via GUI libraries | Via GUI libraries | Yes | Yes through .NET/VO GUI paths | Yes/product dependent | No native GUI |
| Smart table browser/listing | Yes: SmartList, SmartBrowser, SB alias | App/library dependent | App/library dependent | Product dependent | App dependent | Product dependent | No |
| Web/application server | Not main claim | Yes/service/web possible | Some ecosystem support | Yes | .NET web possible | Product dependent | No |
| External app commands | Yes: edit/image/web/url/shell lanes | App code | App code | Product/app code | .NET app code | Product dependent | Python code |
| Build tooling | CMake/WSL/MSVC plus active wx/Tk/GUI lanes; POSIX/Mac requirements still being hardened | hbmk2/build tooling | Build tooling | Commercial Workbench | Visual Studio/.NET tooling | Product installers/tools | Python packaging |
Internationalization, Locale, And Data Types
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| Language/runtime localization | Yes, seeded runtime message catalog plus locale lanes in progress | Yes/ecosystem | Unknown | Product/framework dependent | .NET globalization available | Product dependent | Python locale/libs |
| International text/codepages | In progress; classic/VFP codepage work should be documented carefully | Yes | Unknown | Yes/product dependent | .NET Unicode/globalization | Product dependent | Varies by library |
| Currency data type | Yes, VFP currency/newer type support evidenced | DBF/RDD dependent | DBF/RDD dependent | Yes/product dependent | Runtime dependent | Yes in VFP/dBASE variants | dbf supports Decimal currency |
| Date/datetime/logical/numeric types | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Message catalog | Yes, runtime catalog, import/reset/reload scripts, and GUI message-contract lane | Tooling/ecosystem | Tooling/ecosystem | Product/framework dependent | .NET resources | Product dependent | Python ecosystem |
| Locale-aware formatting | In progress; messaging and language seams are in place before wider shell replacement | Yes/ecosystem | Unknown | Yes | Yes | Product dependent | Python ecosystem |
Documentation And SelfDoc
| Feature | x64base / DotTalk++ Workbench | Harbour | xHarbour | Alaska Xbase++ | XSharp | dBASE / DBF tools | Python DBF libs |
|---|---|---|---|---|---|---|---|
| Built-in help | Yes | Yes | Yes | Yes | Yes | Yes | Package docs |
| Self-documenting source/contracts | Yes, major lane with usage contracts, comment harvesting, and command-help feeds | Not same claim | Not same claim | Product docs/workbench | Tooling/docs | Product docs | No |
| Manual generation | Yes, manualgen/MDO lanes plus website publication feed | hbdoc/tooling exists | Unknown | Product docs | Tooling/docs | Product docs | No |
| AI-friendly documentation layer | Yes, planned/developing | Not same claim | Not same claim | Not same claim | Not same claim | Not same claim | No |
| Website generated from docs | Developing vertical content generation | Project website/docs | Project docs | Product website/docs | Project docs | Product docs | Package docs |
Application UI DSL Gap
DotTalk++ can currently define repeatable database/runtime behavior through commands and DotScript, but it does not yet offer a general language for creating custom menus, windows, dialogs, popups, controls, and event handlers.
The proposed lane starts with this syntax seed:
CREATE MENU MainMenu
CREATE WINDOW CustomerWin
CREATE DIALOG EditCustomer
DEFINE BUTTON Save
ON CLICK DO save_customer
This is a planned lane, not current runtime syntax. It would let future DotTalk++ scripts define small database applications that can target Arctic TUI first, then Parallel GUI/TUI, wxWidgets GUI, and web surfaces later.
Unique And Oddball Features
The tables above compare like against like. This one does not: these are behaviors with no column to sit in, because no other project in the family appears to claim them. Some are genuinely novel; some are simply odd, kept because they turned out to be useful or because they teach something. Each states its evidence tier, and none of them is a reason to choose this project over a mature one.
| Feature | What it is | Tier |
|---|---|---|
| A table whose rows are databases | The workspace catalog is an ordinary table with an ordinary memo field, and a row's payload can be a whole database -- tables, indexes, posture, cursor positions. The inversion of the usual containment: a database contains tables; here a table contains databases | runtime-proven |
| Databases that carry their own address | A saved workspace records the roots its tables live under, so restoring it does not depend on the environment being set correctly first. Proven by breaking the environment on purpose | runtime-proven |
| A session you can resume exactly | Not just which tables were open -- where every cursor sat and which area was selected, restored and then relation-refreshed so children re-slave to restored parents | runtime-proven |
| Hydrate a database into memory in ~70 ms, and write it back | A stored database can be stood up in an in-process RAM filesystem, worked at memory speed, and dropped by unmounting. Rollback is an unmount; commit is a write-back to a real disk root, which refuses a shortfall rather than landing a partial workspace and keeps the replaced files as .__wbak | runtime-proven (hydrate and write-back) |
| Memos that never look at their payload | The memo store is payload-agnostic by design and proven so by an adversarial harness before it was ever asked to carry binary -- which is exactly why databases can ride in it now | runtime-proven |
| A zoo as a test harness | The orthogonality proof is a seeded ecology of six "species" -- driver personas with names like Fawn and Serpent -- run for 20,500 generations against a shadow-model oracle. It came from an external AI's whimsical spec, mapped rather than adopted | runtime-proven |
| Regressions that carry their own doctrine | Each regression entry stores not just what it tests but why it exists, what defect birthed it, and what it deliberately does not claim -- and the public list is generated from that same table, so it cannot flatter the engine | runtime-proven |
| Tests that record when they were wrong | When a test's subject moves, the record says so rather than quietly retuning: a three-month-old memo canary was re-measured green by accident and its status updated in place, next to the original red expectations | runtime-proven |
| Governance that measures itself | The project's rulings page is generated from canonical sources and once caught its own maintainers' hand-kept count drifting -- the derived figure won, and the incident is kept visible | runtime-proven |
| A BBS inside the database engine | Boards, threads, posts, permissions and identity, implemented as ordinary tables and reachable from the shell and a loopback daemon -- the collaboration surface dogfoods the storage engine | source-evidenced |
| An engine that documents itself into its own tables | Command help, topics, and localization live in DBF tables the engine reads at runtime, and the manuals are generated from them -- the documentation is data the database serves about itself | runtime-proven |
Summary Position
x64base should be positioned as:
An educational-first, open, object-oriented hybrid xBase/DBF architecture project exploring 64-bit DBF-style tables, memos, indexes, metadata, command runtime behavior, GUI/TUI tooling, and repeatable self-documentation.
It should not be positioned as:
- a drop-in Harbour replacement
- a drop-in Xbase++ replacement
- a finished commercial DBMS
- a fully compatible Visual FoxPro clone
- the only 64-bit xBase-related technology
What is actually claimed for x32
The list above states what x64base is not. This states what it does claim.
For classic 32-bit xBase formats, x64base claims exactly two things: table operations and host services. Table operations means reading and writing DBF-family tables - their headers, field types, records, memos and indexes. Host services means what the surrounding runtime provides.
Nothing else is claimed. Not language compatibility, not runtime compatibility, not feature parity with any 32-bit product, and not application portability.
Comparisons here inform direction; they are not promises. The tables on this page, and the FoxPro / Clipper / Harbour / Xbase++ comparisons elsewhere in these docs, are used to decide which capabilities are worth building and to locate gaps. A "Yes" in a comparison row is not a compatibility guarantee: a comparison describes two systems, whereas a compatibility claim asserts that one will run the other's work.
For the capacity side of this comparison, see x64 Capacity Math. That page separates published ecosystem limits from x64base source-evidenced limits and planned x64 widening work.