The engine is the base of everything on this site: a C++20 runtime that opens, indexes, relates, validates, and scripts DBF-family data -- classic x32, Visual FoxPro, and the project's own 64-bit x64 format -- under the DotTalk++ command shell. It is active beta, stated plainly, and its habit is to prove behavior with regressions and oracles rather than describe it.
This page is the map. Each panel below is one aspect of the engine and links to the page that covers it completely -- the detail lives there, not here.
Start here
| Panel | What you will find |
|---|---|
| Engine Specifications | The measurable shape on one page: formats, ceilings, defaults, subsystems, verification -- every figure with its source |
| Proven Capabilities | The distinctive behaviors, each with its evidence tier and its proof named -- including the corrections |
| Architecture | The layering: libraries, command host, seams, and why every boundary is a real compilation boundary |
The storage layer
| Panel | What you will find |
|---|---|
| DBF_64 Specification | The 64-bit table format: header, geometry, record addressing |
| x64 Capacity Math | What the widened fields actually buy, computed rather than asserted |
| DBF Flavors and Index Defaults | x32 / VFP / x64 recognition and per-flavor index policy |
| FPT64 Memo Format | 64-bit memos: object ids, append-new semantics, payload agnosticism |
| CDX / LMDB Indexing | The index family and the LMDB-backed keystore |
| Indexing Rules | Attach, rebuild, order, and seek behavior as policy |
The runtime
| Panel | What you will find |
|---|---|
| Workspaces | Sessions as values: snapshots, the catalog, RAM hydration, databases inside memo fields -- and the honest state of simultaneous use |
| RAM DBF and VDISK | The in-process RAM filesystem: tables and indexes with zero files on disk |
| ACID and the Glass-Box Engine | What is transactional, what is cooperative, and what is deliberately visible |
| Error Codes | The error surface |
| API Reference | The programmable seams |
| Python Integration | pydottalk and its boundaries |
Verification
| Panel | What you will find |
|---|---|
| Regression and Proof Testing | The curated suite, generated from the engine's own registry so it cannot drift |
| Runtime Footprint | What actually ships: one executable, two carrier DLLs |
Context
| Panel | What you will find |
|---|---|
| xBase Ecosystem Context | Where this sits among Harbour, xHarbour, Xbase++, XSharp, and the DBF tool families |
| Ecosystem Feature Comparison | The like-for-like tables -- and the unique-and-oddball table for the behaviors with no column to sit in |
| Schemas | The teaching systems the engine runs, ending with the table whose rows are databases |
| Current Project Truth | Status, honestly |
Reading the status language
One convention makes every page above trustworthy: claims carry tiers. Runtime-proven means a transcript or regression shows it. Source-evidenced means the mechanism is confirmed in source but the end-to-end run has not happened. Chartered means designed and registered, not built. Absent means absent. Complete is not bragging when it is true -- and the tier system is what keeps it true.