x64base
A glass-box database engine for building and teaching data systems.
x64base is the stateful substrate of a configurable Laboratory Campus. DotTalk++ makes the engine executable and observable; SelfDoc and MDO turn source, HELP, metadata, contracts, and proof into documentation and curriculum. The goal is a glass-but-real system whose development can be inspected, taught, and improved from the same evidence.
x64base engine: active beta / proof-gated SDLC
Recent runtime proofs: two independent relational walkers agreeing over a 34-table ERP (2026-08-10), a database posture saved into and restored from a memo field, and a seeded stress harness clearing 104,044 chaotic operations against the memo store without a divergence (2026-08-11). Each is listed with its evidence tier on Proven Capabilities.
From the Quantum Memo Zoo to MiniDB
engine status
DotTalk++ CLI + DBF runtime + metadata validation
x64base Engine
DBF-style runtime, x64-family table work, indexes, memos, work areas, and validation.
active beta / proof-gated · latest state in runtime evidence
OpenDotTalk++
A readable command language for teaching, inspection, and scripted workflows.
active beta / proof-gated · latest state in docs progress
OpenDotScript
The script language product for repeatable command files, loops, variables, comments, and automation.
active beta · latest state in language guide
OpenTupTalk
Tuple-centered tools for row inspection, export, validation, and record movement.
active beta · latest state in runtime evidence
OpenRelTalk
A relation-focused layer for declared relation graphs, traversal, workspace persistence, and connected data exploration.
core runtime-proven; join/browse surfaces explicit-run · latest state in runtime evidence
OpenSQLsel
The house SELECT over open work areas: selection, projection, ORDER BY, LIMIT, COUNT(*) -- every shipped operator verified against a SQLite oracle. An x64base set algebra under construction, operator by operator.
shipped operators oracle-proven; joins in a future phase · latest state in runtime evidence
OpenMemoTalk
The memo as a byte carrier rather than a text field: notes, workspace postures, and whole databases living inside a single memo field, with a catalog table whose rows are databases.
runtime-proven; container format and catalog landed · latest state in runtime evidence
OpenLaboratory Campus / LabTalk
The configurable education and collaboration campus where engine work, tools, documentation, and proof become lessons.
alpha campus; shipped lessons proof-backed (a deliberate hybrid) · latest state in curriculum
OpenLMS boundary
Learning modules, without pretending to grade students.
LabTalk can organize lessons, cases, evidence, and local delivery messages, but it is not currently a full learning-management system. It does not enroll or grade students. A lesson module can stand alone, become an agent skill or plugin, or later connect to an external LMS through the reserved provider-neutral boundary.
Lessons, cases, schemas, and proof can travel as a focused teaching unit.
An AI-facing package can reduce the same material to a governed capability.
A host can add the module without turning LabTalk into the host LMS.
supporting architecture
Extension seams remain inspectable.
Architecture supports the learning module and runtime; it is not the homepage hero. Index backends, workbench front ends, extension commands, and lifecycle hooks remain visible as evidence-bearing implementation boundaries.
Open Index API
Indexing is not a sealed implementation detail. x64base publishes attach, rebuild, order, seek, and verification seams so CNX, CDX, LMDB, INX, and teaching-lab formats can be reasoned about as architecture.
Workbench Front Ends
GUI, TUI, and scriptable workbench surfaces are consumers of the same runtime truth. Ordering, cursor state, relations, validation, and command execution stay in DotTalk++ and the engine, not in duplicate UI logic. The schema, the command surface and the portal are documented in enough detail that UI work here is AI-EXPECTED: an agent should be able to read the specification and generate a front end without a human relaying it. That expectation is the reason the API is being opened in spec rather than left as an internal seam. Cross-language C++ and Python CRUD examples continue as the worked templates.
Custom Commands and Functions
Built-in commands stay centrally governed, while student and local extensions can self-register through protected extension lanes. The same pattern supports custom functions, controlled hooks, and curriculum work.
Polling, Triggers, and Lifecycle Hooks
Pre/post polling seams, command lifecycle observation, mutation hooks, and relation/order maintenance are treated as explicit integration boundaries. They belong to the engine contract, not to ad hoc side effects.
start points
A practical place to begin.
Source, build notes, runtime evidence, and generated-documentation paths are gathered without turning the homepage into a release page.
Source, build notes, runtime footprint, command catalog, and evidence starting points.
The visible doorway into campus cases, source-memory stories, and the systems storyboard deck.
Why dottalkpp.exe is the full command/runtime host while LMDB and SQLite stay external.
SelfDoc, MDO, generated manuals, diagrams, matrices, and reviewed documentation layers.
Nine-gate publication status, accepted manual metadata, Pinocchio follow-up, and separate backlog missions.
documentation
Readable status for real implementation work.
The site tracks reviewed implementation truth: C++20 CMake build options, DotTalk++ command surfaces, workspaces over DbArea objects, object-oriented memos, custom field type hooks, Open Index API, Open GUI API, and runtime validation work.
research context
The xBase ecosystem is still alive.
x64base belongs in the xBase conversation, but it is not a claim to replace every compiler, migration tool, DBF library, or commercial modernization platform. It is a focused 64-bit DBF-style architecture experiment with a recognizable table workflow.
Read the ecosystem contextView the feature comparisonOpen-source, commercial, migration, DBF-engine, and legacy branches all still matter.
Classic DBF-family formats carry structural assumptions from earlier computing eras.
x64base uses its own metadata and documentation infrastructure to describe, validate, and increasingly prove itself.
A feature matrix compares x64base with Harbour, xHarbour, Alaska Xbase++, XSharp, dBASE tools, and Python DBF libraries without overstating active-beta work.
DotTalk++ can script database workflows today; the Application UI DSL lane explores menus, windows, dialogs, controls, and event handlers for future TUI/GUI targets.
Co-development documentation
SelfDoc and the Master Documentation Organizer are part of the engine’s working loop, not a separate after-the-fact publishing process.
Build with the engine
Start with the DBF_64 and FPT64 references, then move into APIs and index rules.
Teach with the shell
Use DotTalk++, DotTalk++ Workbench, Parallel GUI/TUI, Arctic TUI, and Laboratory Campus material for labs, front-end learning, command literacy, and database fundamentals.