26 August 2026 — DataFlex 27.0.97.107 with toolchains 0.1.10

In this release

This is the first Technical Preview release of the DataFlex TechStack documented on this site. It ships the new compiler, runtime and debugger as toolchains, installed alongside DataFlex Windows and driven from the same Studio. Three changes carry the release: applications can now run in the browser as WebAssembly, the data model was rebuilt around entities declared in source, and the platform-specific pieces of the runtime — HTTP, files, locale, security — were replaced by portable implementations.

Component	Version
DataFlex Studio and Windows	27.0.97.107
DataFlex Windows toolchains	27.0.0+windows-64, 27.0.0+windows-32
TechStack toolchains	0.1.10+native-64, 0.1.10+native-32, 0.1.10+wasm-32

The Studio

The Studio remains a Windows application and is the single development environment for both generations.

The 32-bit/64-bit platform selector in the toolbar has been replaced by a toolchain selector: a project now selects a specific toolchain rather than a Windows platform. More toolchains… in that drop-down opens the new Select Current Toolchain dialog, which lists every toolchain the Studio discovered on your system by its <version>+<platform>-<arch> name and its install path.

A workspace now records its flavor. Configure Workspace offers Uses Windows toolchain and Uses new TechStack toolchain, and warns you before switching the flavor of an existing workspace. The New Workspace wizard defaults to the TechStack flavor, and Create New filters the available templates to the workspace flavor.

The table below reports the Studio working against TechStack toolchains only, because that is what this release changes. The WebAssembly column is the status for the wasm toolchains and the TechStack native column for the native builds. DataFlex Windows toolchains are not in the table: a DataFlex Windows workspace keeps the Studio it has today, including the Data Dictionary Modeler, DDO Structure Editor, Database Builder, Database Explorer and the table and connection tools. The Studio is Windows-only, so the macOS, Linux and Unix columns of the roadmap's Studio table are N/A throughout and are left out here.

Studio feature	WebAssembly toolchains	TechStack native toolchains
Compiling	✓	✓
Running	✓ (through the Chromium Debugging Protocol)	✓
Debugging	✓ (through the Chromium Debugging Protocol)	✓
CDS support	✓	✓
Toolchain support	◐ (no toolchain management)	◐ (no toolchain management)
Package Manager	◐	◐
Integrated documentation	◐ (online only)	◐ (online only)
DDO Explorer	✗	✗
Connection Manager	✗	✗
Table Editor and Viewer	✗	✗
DataDictionary Designer	✗	✗
Database Explorer	✗	✗
Database Builder	✗	✗

The database tools at the bottom of that table are built on the FileList, and in a TechStack workspace there is no FileList for them to act on: a TechStack application declares its data in source with Entity … End_Entity instead of FILELIST.CFG and FD files. That is why the Table Editor, Table Viewer, Table Explorer (FileList tables), SQL Connection Manager, Creating a New Table, Add Existing Table, Data Dictionary Modeler, DDO Structure Editor, Database Builder and Database Explorer are hidden in a TechStack workspace. None of this affects DataFlex Windows: those tools are unchanged and fully available in a DataFlex Windows workspace, and the ✗ cells above mean only that a TechStack equivalent is still to be implemented — see the Roadmap.

Templates

Create New offers four TechStack project templates under Projects: Processes, Foundation - Server Data Dense screen, Foundation – Server Drilldown and Foundation – WebAssembly Drilldown. They are the TechStack counterparts of the DataFlex Windows entries with the same names, and the Studio shows whichever set matches the workspace flavor.

Foundation - Server Data Dense screen and Foundation – Server Drilldown both wire cDbConnectionManager with cDbSqliteDriver against sqlite:MyAppDb.db?mode=rwc, so a new project runs against real data immediately rather than after a round of database setup. Foundation – WebAssembly Drilldown gives you a working drill-down application, connected to sqlite:/dev/idbfs/MyAppData.db?mode=rwc so its data lives in browser-local storage. Processes is the starting point for an application with no user interface.

Editor and CodeSense

CodeSense parses entity/end_entity. An entity is completed as a struct, so its fields complete wherever the entity is used, and Go To Definition works for these symbols.

Entity declarations, fields, indexes and relations have their own icons in the code explorer. In a TechStack workspace the class palette lists the classes of the current toolchain instead of applying the Windows/Web filter.

Toolchains in this release

A toolchain packages the compiler, runtime, debugger and core features for one target, and is identified as <version>+<platform>-<arch>. Toolchains explains the model in full.

The two generations version independently, on purpose. DataFlex Windows continues the established mainline and is at 27.0.0 in this release. The TechStack starts counting from scratch to signify that it is brand new and independent of the Windows line — in this release, 0.1.10.

One TechStack toolchain version has several platform builds. 0.1.10 ships as native-64, native-32 and wasm-32. The two native builds are the ones released for the Windows platform in this release; native builds for macOS, Linux and Unix are not part of it. wasm-32 targets the browser rather than an operating system.

Toolchains install under C:\ProgramData\DataFlex\Toolchains and are found automatically from there; set DFTOOLCHAINS to look for them elsewhere. They appear as ordinary Windows installer entries, so they can be installed and uninstalled on the fly, and the bundled set is auto-installed the first time you install the 27.0 Studio. When several versions of a toolchain are installed, the newest is used by default.

New toolchain installers are published roughly every month and can be installed on their own, because Studio changes are deliberately kept to a minimum.

Toolchain build	Version	Target	In this release
27.0.0+windows-64	27.0.0	DataFlex Windows, 64-bit	Released
27.0.0+windows-32	27.0.0	DataFlex Windows, 32-bit	Released
0.1.10+native-64	0.1.10	TechStack native, 64-bit, Windows	Released
0.1.10+native-32	0.1.10	TechStack native, 32-bit, Windows	Released
0.1.10+wasm-32	0.1.10	TechStack WebAssembly, browser	Released

Native builds for macOS, Linux and Unix are not part of this release — see Phase 2 — Cross-Platform Deployments.

What is released, topic by topic

This section walks the released surface area topic by topic. Each topic opens with an explicit Status line, because "released" rarely means "everywhere and complete": it says which platforms the topic is released on, what is only partly there and what is still to be implemented. After that comes what changed and why — the technology the TechStack now uses, and what it replaces. Anything not mentioned here is not part of this release, and the Roadmap carries the full status matrix.

Data, entities and Data Dictionaries

Status: released on WebAssembly and Windows as experimental — usable and documented, but the shape of the API can still change, so treat code written against it as preview code. SQLite is the only database driver in this release; the SQL, DDP and SQLExecutor drivers are still to be implemented, as is this whole area on macOS, Linux and Unix.

The data model was rebuilt end to end. DataFlex Windows resolves tables through FILELIST.CFG and .FD files and reads and writes them through one global File.Field buffer per table, shared by the whole program; a TechStack application declares its data in source with Entity … End_Entity, and each Data Dictionary object owns its own record buffer, so two objects on the same table no longer fight over one buffer. Every database operation now crosses a single documented adapter boundary instead of backend-specific plumbing, and a connection is addressed by URI — sqlite:MyAppDb.db?mode=rwc — with the scheme selecting the driver. Data and its child pages cover entities, Data Dictionaries, data binding, relations, constraints, transactions, the Command API and building your own driver.

New compared with DataFlex Windows: no FileList and no FD files, no global record buffers, and no per-backend driver plumbing — data is declared in source, buffers are local to the Data Dictionary object, and drivers plug into one adapter protocol. SQLite is the driver that ships; on WebAssembly its database file lives in the browser's persistent storage, which is what makes an offline-capable client possible. The SQL, DDP and SQLExecutor drivers are still to be implemented.

Web UI and WebApp Clients

Status: the Web UI framework is released on WebAssembly and Windows, and the WebApp Client is released on WebAssembly. Hosting is released only as the Windows WebApp Server under IIS; the cross-platform WebApp Server, WebAPI framework support and FlexTron are still to be implemented, as is the Web UI framework on macOS, Linux and Unix.

The Web UI object model is unchanged — the same views and controls — but there are now two application roots for it: a server root for native and Windows builds, and a client root for WebAssembly. The same view and control source compiles into either. On WebAssembly the browser downloads the compiled application as a .flx bundle, loads it into the DataFlex WebAssembly runtime in a Web Worker and runs it there, so application logic and UI handling happen locally instead of as a request to a server process. Creating a new project walks through building one.

New compared with DataFlex Windows: the classic Web Framework runs the application on the server, in pooled WebApp.exe processes behind the Windows Web Application Server and IIS, and synchronizes with the browser over JSON requests — a round trip per action. The WebApp Client removes that loop for local work: the server becomes a static host for the bundle and the runtime, and only explicit network calls leave the browser. Nothing like it exists in DataFlex Windows.

HTTP

Status: released and usable on WebAssembly and Windows; still to be implemented on macOS, Linux and Unix. This is the HTTP client; the server-side pieces are named at the end of this topic.

DataFlex Windows does HTTP through cHttpTransfer on top of WinInet, the ageing Windows-only transfer stack, with cJsonHttpTransfer and cXmlHttpTransfer bolted on top to handle JSON and XML and to buffer large responses. All of that is now one class, cHttpClient, on a new portable backend: libcurl with OpenSSL for native builds, and the browser's own fetch API on WebAssembly. Serialization moved into the client too — a DataFlex struct goes out as the request body and a JSON response comes back as a struct — so there is no separate transfer subclass per content type, and file and chunked responses are part of the same class.

New compared with DataFlex Windows: one client class on a cross-platform backend instead of a Windows-only transfer hierarchy, with struct-in/struct-out serialization built in. Two capability differences follow from the platform: proxies, client certificates and HTTP-version selection are native-only, because on WebAssembly the browser owns the connection. SOAP web services (cWebService and WSDL generation) and the classic REST handler cWebHttpHandler are not in this release — SOAP web services and WebAPI framework support are both still to be implemented, on every platform.

URI

Status: released and usable on WebAssembly and Windows; still to be implemented on macOS, Linux and Unix.

DataFlex Windows has no URI parser at all: its HTTP classes take host and path strings, and anything more had to be assembled by hand. cURIParser parses a URI into its parts — scheme, credentials, host, port, path, query and fragment — generates one back, and handles percent-encoding and decoding. It is built on the same regular-expression engine and the same encoders as the rest of the runtime, so it behaves identically on every toolchain.

New compared with DataFlex Windows: DataFlex Windows has no equivalent API. Parsing and generating URIs, and encoding and decoding their components, is new.

Filesystem

Status: released and usable on WebAssembly and Windows; still to be implemented on macOS, Linux and Unix.

The commands are the familiar ones — Direct_Input, Direct_Output, Append_Output, the Read/Write family, Seq_New_Channel — so sequential file code ports across unchanged. What changed is underneath: instead of Windows-oriented device handling, file access now goes through one portable filesystem layer where a path can name a driver, and the driver decides where the bytes actually live. Natively that is the operating system's filesystem; on WebAssembly it is the browser's filesystem, with a persistent area so that files, including a SQLite database, survive a reload. Directory management, path resolution through DF_OPEN_PATH, and block and hex I/O are part of the same API.

New compared with DataFlex Windows: the same commands, a portable implementation. Directory creation and removal, current-directory handling and block and hex I/O are documented as one filesystem API rather than a set of Windows-specific behaviours, and the driver layer is what lets identical source read and write files in a browser.

Locale and date/time

Status: released and usable on WebAssembly and Windows; still to be implemented on macOS, Linux and Unix.

In DataFlex Windows, locale is effectively one global setting — attributes such as DF_LOCALE_CODE, defaulting to the operating system's language — and formatting follows the Windows locale. The TechStack carries its own locale sets, including USA, European, Military and ISO 8601, and documented date and time format patterns, so the same source formats the same way on every platform and in the browser. Locale is also scoped: Push_Locale and Pop_Locale set a locale for a stretch of code and restore the previous one afterwards, instead of changing a global and hoping to change it back. DateTime adds date arithmetic, week calculations and TimeSpan arithmetic.

New compared with DataFlex Windows: locale is program state you can nest rather than a single global tied to the operating system, the format patterns are documented and portable, and TimeSpan gives durations their own type instead of hand-rolled date arithmetic.

Error handling

Status: released and usable on WebAssembly and Windows; still to be implemented on macOS, Linux and Unix.

DataFlex Windows routes every error to one place: the global error object and its Error_Report handler, with the obsolete On_Error as the only other option. That is fine for reporting and awkward for recovery, because the code that knows how to recover is rarely the handler. The TechStack keeps the handler model for anything uncaught and adds Try/Catch as a language construct, so a failing operation can be handled where it happens, with the error number and message in hand.

New compared with DataFlex Windows: protected blocks. Try/Catch is part of the language and the runtime, not a convention on top of the handler, and DataFlex Windows has no equivalent. The grouped DFERR_* error numbers and cBaseErrorHandler carry over.

Reflection

Status: released and usable on WebAssembly and Windows; still to be implemented on macOS, Linux and Unix.

The compiler now emits type metadata alongside the code — the names and types of struct members, the shape of arrays — and Reflection is the API that reads it back at runtime. That makes generic code possible: walk a struct you were handed without knowing its type, build one from a type, read and write members by name, size and traverse arrays, and ask what type the caller expects back.

New compared with DataFlex Windows: DataFlex Windows has no equivalent API, because nothing emitted the metadata to inspect. Generic code had to be written against known types and known members.

Security

Status: released and usable on WebAssembly and Windows, with one platform difference: the encoding, decoding and random-generation functions work everywhere, while certificate handling is native-only because in the browser the connection, and therefore the certificate, belongs to the browser. Still to be implemented on macOS, Linux and Unix.

Security is a new library rather than a port. DataFlex Windows has no general security API: password encryption for managed connections sits in its own class, hashing and randomness reach into the Windows CryptoAPI, and a client certificate is picked out of the Windows certificate store by name. Here, a certificate is a value you load from a file or a string — parsed natively with OpenSSL — and hand to the HTTP client. Encoding and decoding cover Base64, Base32, hex and URI form in one place, and DFSEC_Random produces random bytes or readable random text.

New compared with DataFlex Windows: a documented, portable security API instead of Windows CryptoAPI calls and per-feature classes, with certificates as first-class values. It is the library that will replace the DataFlex Windows security library in the future.

Interop and extensibility

Status: partly released, and the parts differ. External function and DLL calls and the DataFlex Interop API are released and usable on WebAssembly and Windows. FlexCom is released on Windows with limitations: no ActiveX control support and no object nesting. JavaScript interop is released on WebAssembly, but only through the DataFlex JavaScript Worker. Interop on macOS, Linux and Unix is still to be implemented, and FlexCom and JavaScript interop do not apply to those platforms as they stand.

DataFlex Windows reaches outside itself in two ways: External_Function, which imports a named function from a Windows DLL, and COM, through generated wrapper classes over automation objects and ActiveX controls that have to be registered on every workstation. The TechStack keeps the typed external-declaration model but makes what sits behind it portable: natively it loads a dynamic library and calls into it, and on WebAssembly the same declaration reaches JavaScript in the page instead. FlexCom carries COM automation forward on Windows, limited to non-nested objects; ActiveX controls do not come along, because they are registered native UI controls with nowhere to live in a browser. The Roadmap carries the per-platform detail.

New compared with DataFlex Windows: one external-declaration model with a portable implementation underneath, so the same code shape calls a native library or a JavaScript function. COM automation continues through FlexCom on Windows, without ActiveX controls and without object nesting; generated ActiveX control wrappers and per-workstation registration have no TechStack equivalent, and JavaScript interop has no DataFlex Windows counterpart.

Release notes

Studio

• Toolchain selector in the toolbar replaces the 64-bit/32-bit platform selector; a project now selects a toolchain.
• More toolchains… opens the new Select Current Toolchain dialog, listing every toolchain found on the system by <version>+<platform>-<arch> name and install path.
• The toolbar drop-down is filtered by the workspace flavor; More toolchains… force-selects any toolchain on the system.
• Configure Workspace gains Uses Windows toolchain and Uses new TechStack toolchain, and warns before switching the flavor of an existing workspace.
• The New Workspace wizard defaults to the TechStack flavor.
• Create New filters templates to the workspace flavor, regardless of the Only show relevant checkbox.
• New TechStack project templates: Processes, Foundation - Server Data Dense screen, Foundation – Server Drilldown and Foundation – WebAssembly Drilldown.
• In a TechStack workspace the class palette lists the classes of the current toolchain instead of applying the Windows/Web filter.
• Entity declarations, fields, indexes and relations have their own icons.
• CodeSense parses entity/end_entity, completes an entity as a struct, and supports Go To Definition for these symbols.
• The FileList-based database tools are hidden in a TechStack workspace, and FileList tables no longer appear in the Table Explorer.

Toolchains

• TechStack toolchains are found automatically once installed under C:\ProgramData\DataFlex\Toolchains; set DFTOOLCHAINS to look elsewhere.
• A toolchain is selected by its name or by its full <version>+<platform>-<arch> identifier, alongside the existing windows-64 and windows-32 names.
• When several versions of a toolchain are installed, the newest is used by default.
• Toolchains appear as Windows installer entries and can be installed and uninstalled on the fly; the bundled set is auto-installed with the 27.0 Studio.
• TechStack toolchain 0.1.10 ships as native-64, native-32 and wasm-32; the native builds target Windows in this release.

WebAssembly

• Creating a WebAssembly project also creates its virtual directory and its index.html page.
• The Package Manager keeps the script includes in that generated page up to date, even when the page is not named Index.html.
• WebAssembly applications and their .flx bundles are served correctly by the Windows WebApp Server under IIS.
• A WebAssembly application can be installed like a native app: an application manifest and icons are added to AppHtml.
• The WebAssembly runtime is delivered as the DataFlex-dev/WebAssembly Runtime package.
• The same AppHtml can be packaged for Android through the Android Build Service, producing a signed APK and optionally an App Bundle.

Debugger

• The revamped debugger works across the toolchains, native and WebAssembly alike; WebAssembly applications are run and debugged through the Chromium Debugging Protocol.

df-cli

• df-cli build and df-cli build-file accept a TechStack toolchain with --toolchain, which takes a toolchain directory name, an exact <version>+<platform>-<arch> identifier, or the windows-64 and windows-32 aliases.
• df-cli reads the workspace's toolchain flavor and builds with the matching toolchain.
• df-cli system reports the resolved default toolchain; df-cli toolchain list lists discovered toolchains; df-cli toolchain info <name> reports a toolchain's name, version, root and its compiler, runtime and debugger paths.
• A WebAssembly project's generated HTML page is picked up when building from the command line.
• Installing and uninstalling toolchains still goes through the Windows toolchain installers; df-cli-managed toolchain installation is not part of this release.

Data

• Applications declare their data in source with Entity … End_Entity; fields carry attributes such as { Type=NVARCHAR, Length=100 }, { PrimaryKey=On }, { AutoIncrement=On } and { Unique=On }, and entities declare their own Add_Index and Add_Relation.
• Record buffers are local to the Data Dictionary object rather than shared global File.Field buffers, and data binding addresses the DDO — Entry_Item oCustomerDD.Name.
• The Command API in Use Db\DBCommands.pkg provides Begin_Transaction, End_Transaction, Clear, Constrain, Delete, Entry_Item, Find, Get_Field_Value, Relate, SaveRecord and ZeroFile.
• Relations are declared on the entity with Add_Relation and connected between Data Dictionary objects with Set DDO_Server.
• Connections are registered through cDbConnectionManager with a driver class; cDbSqliteDriver ships as the SQLite driver.
• cDbTransactionManager exposes BeginTransaction, CommitTransaction and RollbackTransaction beneath the Begin_Transaction/End_Transaction commands.
• Building your own database driver is documented, including the driver adapter protocol, cDbFlexAdapter_mixin and tDbMessage/ProcessMessage.
• HTTP data synchronization and browser-local database storage are available for WebAssembly applications.

Compatibility notes

• TechStack reference documentation — Getting Started, toolchains, the data model and the API reference — is published online only during the Technical Preview, at https://tsdocs.dataflex.dev/. The offline CHM help shipped with the product documents the DataFlex Windows toolchain.
• A TechStack workspace defines its data in source with Entity … End_Entity instead of FILELIST.CFG and FD files, so the FileList-based database tools are hidden and FileList tables no longer appear in the Table Explorer.
• A workspace file records whether it uses the DataFlex Windows toolchain or a TechStack toolchain. A workspace created before the Technical Preview, or edited by hand without that setting, is treated as a TechStack workspace.
• A sample cannot be switched to a different toolchain and recompiled in this preview: the Windows UI sample is not supported on the TechStack, and the Web UI and Server samples do not work by switching toolchains. Explore the TechStack samples directly instead.
• Mixing both flavors in a single workspace is technically possible but not recommended: the Studio needs one flavor per workspace, though individual projects within a flavor may each use a different toolchain and toolchain version.
• FlexCom is available on Windows with limitations: no ActiveX controls and no object nesting. JavaScript interop on WebAssembly is limited to the DataFlex JavaScript Worker.
• Integrated Studio documentation is online only in this release.

For what is available on which platform, see the Roadmap.