Architecture

How the platform is built

OES is written in C++17 on wxWidgets. It builds with MSVC on Windows, with GCC on Linux and with Clang on macOS, and CI runs the tests on all three. The full description is in ARCHITECTURE.md.

Programs and libraries

 launcher   designer   enterprise   codeRunner        appserver   wenterprise-server
     │          │           │            │                 │               │
     └──────────┴─────┬─────┴────────────┘                 │               │
                      ▼                                    │               ▼
                 frontend          (desktop UI)            │           wfrontend   (web UI)
                      │                                    │               │
                      └──────────────────┬─────────────────┴───────────────┘
                                         ▼
                                      backend      (the engine, no UI)
                                         │
                        Firebird · PostgreSQL · ODBC · SQLite

Part	What it does
backend	The engine: metadata, the compiler and bytecode interpreter, the query engine and the report composer, sessions, locks, jobs, the database layer, the debugger server, the MCP server. It has no UI
frontend	The desktop interface: forms and their controls, the main window, editors
wfrontend	The same forms and controls, drawn in a browser
The programs	Each one picks how it holds a base and what kind of session it opens, then hands over to the libraries

Inside the engine

Subsystem	What it does
Metadata	Holds the configuration as a tree of objects. Applying compares it with the base and changes the tables by a diff, showing the exact DDL first
Compiler	Lexer, parser, bytecode (82 opcodes), interpreter, LINQ. Compiled modules are cached per configuration version
Query engine	Parses the query language, renders it to the dialect of the database, or runs it in memory when SQL cannot express it
Composer	Turns a report's settings into a query and its result into a spreadsheet
Sessions	One per user, job or service. A session holds its connection, its running code and its windows
Locks	Record locks shared across processes, so two servers on one base do not overwrite each other
Jobs	Scheduled and background jobs; a job runs once across all servers sharing a base
Database layer	One interface over Firebird, PostgreSQL, ODBC and SQLite; every statement is prepared, never concatenated
Debugger	A TCP server in the running application; the designer connects to it
MCP server	The assistant's access to the designer: about a hundred tools, protected by a token, every call journalled

Processes and bases

A desktop program holds one base. The application server holds several. Every base has its own connection pool, sessions, locks, jobs and journal, and a thread always works for a definite base: there is no global "current" one.

Databases

Database	Role
Firebird 5	The default. Embedded in the packages: a file base needs no server
PostgreSQL	Production with several users
ODBC	The road to other databases
SQLite	Tests and logging

Where to read more

• ARCHITECTURE.md: the system, directory by directory
• docs/public/: design documents (the client protocol, dates, event handlers, functional options, HTTP, JSON)
• development.md: how changes are made and reviewed