This FAQ is organized by how the project is actually described on the site: products, tools, lanes, formats, and proof status.
FAQ reviewed 2026-08-26. Each full-stack documentation reconciliation must check this page against changed product, command, interface, workspace, and contributor-operation claims. The matrix records
UPDATEDorNO_CHANGE, and the site freshness gate binds this review date to the documentation-progress authority.
Products
Is this a clone of classic xBase?
No. x64base is a lineage evolution. It keeps the practical clarity of xBase tables, work areas, records, indexes, and command-driven workflows while modernizing the architecture around 64-bit formats, explicit specifications, object-oriented runtime services, documentation metadata, and cross-platform build lanes.
See: Engine Architecture, Ecosystem Feature Comparison
What is x64base?
x64base is the database/runtime side of the system. It handles DBF-family table work, work areas, cursor state, records, fields, memos, indexing, metadata, validation, and relation-aware runtime behavior exposed through DotTalk++.
It is best described today as active beta engine work, not a finished standalone commercial database product.
See: x64base Engine, Feature Crosswalk
What is DotTalk++?
DotTalk++ is the canonical command shell and runtime vocabulary for x64base. It exposes commands for opening tables, browsing records, moving cursors, loading workspaces, inspecting relations, mutating data, generating help, validating metadata, and running repeatable scripts.
DotTalk++ is active beta. Some command families are runtime-proven; others are canaries, integration surfaces, or planned lanes.
See: DotTalk++, DotTalk++ Language Guide
What is DotScript?
DotScript is the productized script form of the DotTalk++ command language. It is for repeatable command files, labs, validation runs, and automation.
Current documented syntax includes variables, comments, line continuation, IF / ELSE / ENDIF, LOOP / ENDLOOP, WHILE / ENDWHILE, UNTIL / ENDUNTIL, SCAN / ENDSCAN, one-level subscript nesting, and CSV/DBF import-export workflows.
See: DotScript, DotScript Language Guide
What is DotTalk++ Workbench?
DotTalk++ Workbench is the family name for GUI, TUI, CLI, browser, and preview surfaces over the same runtime concepts. The goal is parallel visibility: a table, workspace, relation, command, or proof should be inspectable from more than one surface without changing the underlying runtime truth.
See: Parallel GUI/TUI, Parallel GUI/TUI Docs
What is Arctic?
Arctic is the code name for the DotTalk++ Workbench TUI surface. It should not be used as the product family name. Use DotTalk++ Workbench for the family and Arctic TUI for the terminal interface lane.
See: Arctic TUI, Runtime Evidence Gallery
What is the Laboratory Campus?
The Laboratory Campus is the learning and collaboration layer for x64base and DotTalk++. LabTalk remains the project mark and legacy name, but public copy increasingly emphasizes the campus.
The campus is alpha: it mixes planning material, existing evidence, in-development labs, datasets, cases, GUI experiments, and proof-backed lessons.
See: Laboratory Campus, Laboratory Campus Overview
Tools And Commands
What are workspaces and areas?
Workspaces are wrappers over active database areas. An area is the runtime place where a table, cursor position, index order, relation state, memo behavior, metadata, and buffering state can be inspected and controlled.
This is why x64base is described as an object-oriented hybrid: classic xBase ideas remain visible, but the runtime organizes them through explicit service objects and work-area state.
See: Engine Architecture, Getting Started Overview
What is MINIDB -- is it only metadata about another database?
No. A MINIDB 1 memo container carries the database itself: workspace posture,
table bytes, and native index bytes. The demonstrated development path can inspect
that container and hydrate its members into the in-process RAM filesystem without
using the original disk tables as its source.
That makes the workspace catalog a database of databases, not merely a catalog of database descriptions. The feature is Alpha development work, and a stored snapshot does not imply that every recursive or concurrent workspace operation is complete.
See: In-Memory Databases, Workspaces
Do MINIDBs have "minispaces," or can workspaces be nested?
"Minispaces" is a useful joke, not a product name. The serious idea behind it is active Alpha work: multiple workspaces, recursive inspection, and nested containers. The site distinguishes the already demonstrated MINIDB save/inspect/hydrate path from the still-developing manager behavior around concurrency, recursion, nesting, and lifecycle control.
See: Workspaces, Current Work Lanes
What are TupTalk, TableTalk, and RelTalk?
- TupTalk names tuple-facing relation output and joined record views.
- TableTalk names table buffering, including dirty and stale table state.
- RelTalk names relation-facing workflows such as relation trees, descendant summaries, and relation-aware browse output.
These are lanes and product names around actual runtime concerns, not interchangeable labels.
See: TupTalk, TableTalk, RelTalk
What browsing and listing tools exist?
The site documents several table and browser surfaces, including SMARTLIST, SMARTBROWSE, SM, SMART, SIMPLEBROWSE, SB, BROWSE, BROWSER, BROWSETUI, ERSATZ, and RBROWSE.
SB is an alias for SMARTBROWSE. Browser names should be documented from command evidence, not inferred from labels.
See: Command Catalog, Runtime Evidence Gallery
What commands mutate data?
Data mutation needs special treatment because it changes records or buffered state. Important mutator families include REPLACE, CALC, CALCWRITE, and multi-record/multi-replace workflows such as MULTIREP.
Mutation behavior must be documented against buffering state: unbuffered writes, table-buffered writes, dirty rows, stale fields, validation failures, and commit/writeback boundaries are not the same thing.
See: DotTalk++ Data Mutators, SET Family
Does DotTalk++ support external tools?
Yes, some command families call external apps, shell behavior, images, web URLs, or helper tools. These commands should be documented with the same care as database commands because they cross a boundary outside the runtime.
See: Command Catalog, Coding Standards
Are there education commands?
Yes. The Laboratory Campus documentation tracks education-facing commands and lessons, including areas such as ASCII, SHELLO, RETRO, timed IDX labs, pre/post polling hooks, student code hooks, datasets, and proof transcripts.
See: Education Features, Laboratory Campus Examples
Lanes
What is a lane?
A lane is a named workstream with its own proof status. Examples include engine work, DotTalk++ commands, DotScript, SelfDoc, manual generation, Laboratory Campus lessons, GUI/TUI surfaces, historical source preservation, and the proposed application UI DSL.
Lanes prevent the site from flattening active, planned, proven, and experimental work into one vague product claim.
See: Current Work Lanes, Website Documentation Matrix
What is the SelfDoc lane?
SelfDoc is the documentation and metadata lane that collects command help, source comments, contracts, metadata, proof reports, and manual-generation artifacts. It is part of the system architecture, not just a publishing chore.
The long-term goal is vertical content generation: a command or feature update should flow from source and HELP metadata through SelfDoc/MDO reports into manuals, diagrams, and website sections.
See: SelfDoc Feed Pipeline, SelfDoc Website Publication
What is the Master Documentation Organizer?
The Master Documentation Organizer is the organizing layer for generated and curated documentation. It is intended to help gather command contracts, metadata, help text, proof artifacts, diagrams, screenshots, and manuals into repeatable publication paths.
See: Important Documents, Website Documentation Matrix
What is the application UI DSL lane?
It is an Alpha implementation lane for user-defined menus, windows, dialogs, controls, and event handlers. A DBF/FPT design-table contract, importers, manifest/refusal checks, and early wxWidgets, Tk, HTML, and character-cell consumers exist in development.
The text-command layer is still planned. DotTalk++ does not yet provide a
finished FoxPro-style CREATE WINDOW / DEFINE BUTTON language for custom
applications, and the known target-specific proof limits remain visible.
Example direction:
CREATE MENU MainMenu
CREATE WINDOW CustomerWin
CREATE DIALOG EditCustomer
DEFINE BUTTON Save
ON CLICK DO save_customer
What is the historical source lineage lane?
It preserves earlier xBase, XDLL, xBase2, original C-era DotTalk work, recovery folders, AI-assisted false starts, and modern DotTalk++ with checksums, labels, and feature tags.
This lane exists because the project history matters: the modern system is larger than the original code, but the original source provides important provenance.
See: Historical Source Lineage
Formats And Engine
What table formats are used?
The project works with DBF-family formats, including classic/MS-DOS DBF, VFP-style DBF, and x64 DBF_64 work. DBF_64 is the newer 64-bit table direction, not the only DBF flavor named on the site.
See: DBF Flavors and Index Defaults, DBF_64 Specification
What memo formats are used?
FPT64 is the documented 64-bit memo direction. The memo subsystem is also discussed as an object-oriented architecture with MemoRef, MemoManager, MemoObject, and MemoStore concepts.
See: FPT64 Memo Format, Engine Architecture
What indexing work exists?
The site documents INX, CNX, CDX, and LMDB-backed indexing work, including default and optional index choices by DBF flavor where known. Some indexing work is runtime-proven; some is active integration work.
See: Indexing Rules, CDX / LMDB Indexing
Does x64base support CSV import and export?
Yes, CSV import/export and DBF/CSV workflows are part of the documented command and DotScript surface. Those flows should be tied to command evidence and not described as a generic spreadsheet feature.
See: DotScript Language Guide, Command Catalog
Does x64base support DDL?
DDL is documented as a command family and should be tracked with command catalog evidence, data dictionary behavior, schema/proof artifacts, and any limits discovered by runtime tests.
See: Command Catalog, Feature Crosswalk
What about record locking, triggers, buffering, and cursor control?
These are commercial-database-style feature areas tracked in the engine and command documentation. The site should distinguish runtime-proven behavior from active or planned work.
Buffering is especially important: TableTalk tracks table-buffer state such as dirty rows, stale fields, validation failures, and writeback behavior.
See: Feature Crosswalk, DotTalk++ Data Mutators, SET Family
What about language, locale, currency, and international support?
The system tracks locale, language, settings, and field/data type work as part of the engine and SET-command family. International currency and locale behavior should be documented from actual command coverage, field-type behavior, and tests.
See: SET Family, Feature Crosswalk
Interfaces
What interfaces exist today?
The documented interface surfaces include:
- DotTalk++ CLI command shell.
- Arctic TUI code-name surface.
- DotTalk++ Workbench GUI and preview lanes.
- Python/Tk preview tools.
- Website documentation and product pages.
Each surface should point back to runtime evidence when possible.
See: Parallel GUI/TUI, Runtime Evidence Gallery
Can users build their own GUI screens in DotTalk++ today?
Not yet through a finished user-facing DotTalk++ language. The Alpha UIDEF lane can already describe an application in DBF/FPT design tables and feed early wxWidgets, Tk, HTML, and character-cell consumers. Existing Workbench surfaces can therefore exercise real implementation, but the proposed text verbs, cross-target parity, and remaining native proof are not complete.
Is the website itself an x64base product?
Yes, conceptually. The website is part of the product system because it publishes x64base/DotTalk++ documentation, proof artifacts, diagrams, screenshots, generated content, and curated explanations.
Practically, the website is currently a separate static site project. The intended direction is to keep aligning it with the SelfDoc/MDO vertical feed so source truth, HELP, contracts, manuals, and website pages do not drift.
See: Website Documentation Matrix, SelfDoc Website Publication
Local Preview And Contributor Surfaces
What is the difference between ports 3000 and 3002 locally?
The website development server listens on port 3002. The local AI reports gateway
listens on port 3000: it serves /AI/ and /AI/console, and proxies ordinary
website routes to 3002. Use the normal start-ai.ps1 launcher so it verifies that
the expected ports are free and checks gateway health instead of adopting or killing
an unknown listener.
Search needs a production-built Pagefind index. Use the launcher's built mode when testing search; ordinary Next development mode is for live editing.
What is /lab, and is it published?
/lab is a local-only working surface for experiments, inventories, and
review-needed material that should not yet become a public claim. Its index lists
nested Lab pages such as /lab/experimental in local preview. The route is noindex,
removed from publication output, and protected by a publication abort if it survives
the strip step.
Do not link public documentation to a Lab page. Promote the underlying content into the appropriate public documentation lane first.
Why can /lab still show a route-parameter error after its source is fixed?
The Lab uses an optional catch-all route. Static export requires its parameter list
to include both the empty root slug and every nested content slug. Changes to
generateStaticParams() are startup-time route changes, so an already-running Next
development server can keep the old list. Restart only the verified website server
on port 3002; preserve the reports gateway on port 3000.
The proof is not merely that the build exits successfully. The export must contain
both out/lab/index.html and the expected nested Lab pages, and the proxied /lab/
request must return the Lab index without a runtime error.
Status And Proof
What does runtime-proven mean?
Runtime-proven means the behavior has current evidence: source, command output, screenshots, transcripts, smoke tests, generated reports, or reviewed artifacts. It does not mean every edge case is complete.
See: Runtime Evidence Gallery, Feature Crosswalk
What is active beta versus alpha?
x64base and DotTalk++ are active beta: real runtime behavior exists, but the project is still evolving.
The Laboratory Campus is alpha: it combines collaboration planning, teaching material, existing screenshots, datasets, cases, and in-development tools.
Planned lanes, such as the application UI DSL, should stay labeled as planned until implemented and proven.
See: Current Work Lanes, Laboratory Campus SDLC
Why so much emphasis on education?
Because database systems become understandable when learners can inspect the layers: file formats, fields, indexes, work areas, relations, buffers, commands, help text, diagrams, and proof artifacts.
The educational goal is not to simplify the system into slogans. It is to make the real machinery visible enough to learn, test, extend, and document.
See: Laboratory Campus Overview, Education Features
How should new features be documented?
New commands, functions, field types, or interface behavior should move through the same vertical path:
source / command -> usage contract -> HELP / metadata -> SelfDoc report
-> proof artifact -> manual section -> website section
That is the repeatable path the site is trying to expose.