The architecturally honest options for Informix 4GL modernization are these. Full rewrite — multi-year, open scope, business-logic rediscovery, no guarantee of feature parity. Vendor screen-scraper — opaque, brittle, indefinite licence dependency, dictated upgrade cadence. Status quo — works fine until the people who can read 4GL retire. Nexus is a fourth option whose architectural shape exists precisely because none of the first three was acceptable.
The product boundary is drawn at the PTY. Anything inside is the 4GL’s domain; anything outside — observation, rendering, audit, transport, policy — is Nexus’s. The boundary is deliberately narrow. Crossing it (modifying the 4GL, intercepting business logic, replicating runtime state) is explicitly out of scope. The unmodified-runtime guarantee is not an aspiration; it is enforced by where the architecture draws its lines.
Runtime wins over backend; backend wins over front end. The front end observes and renders; it never independently initiates. A button click in the browser is a keystroke forwarded to the PTY, and the resulting screen change is observed in the PTY output — not predicted in the browser. Any feature whose correctness depends on the front end or backend overruling the runtime is, by construction, not implementable in this platform.
The core platform (sessions, synchronization, audit, policy, security, replay, front end communication) has no knowledge of Informix 4GL specifics. Runtime-specific behaviour (.per parsing, .frm decompilation, terminal decoding, validator dialects) lives inside a runtime adapter loaded at startup. Adapters version independently from the daemon; a daemon refuses to start with an adapter whose declared API version does not match its own. The first adapter targets Informix 4GL — but the core makes no assumption that there will only ever be one.
TLS-mandated WebSocket transport (RFC 6455), mandatory client masking, structured framing, versioned protocol negotiation. A daemon may serve multiple front end protocol versions simultaneously during a rolling upgrade; an unsupported version is a clean refusal, not a silently degraded session.
Every customisation an operator can make through the in-browser Designer or Theme editor lands as YAML — form_overrides: for label / hidden / order / position changes, chrome: for theme chrome, themes[] for full named theme alternates. The runtime sees none of it. A reorganised form looks different in the browser; the 4GL still believes its fields are in the order the .per file declared. This is “UI is a detective, not a director” expressed as schema: the override schema is purely presentation-side, and the parser refuses anything that would require changing runtime behaviour.
Because the platform observes rather than rewrites, the exit path is mechanically simple: stop the daemon and the 4GL is reachable via its terminal interface exactly as it always was. There is no data captured by the platform that the 4GL did not already own. There is no schema the platform imposes. There is no runtime contract the application depends on. Vendor lock-in is bounded by what the platform adds (browser UI, audit, replay) and reverts cleanly when removed.
See the DBA view for the operational and audit detail, or the Management view for the commercial framing. Call +1-913-732-8892 (US) or +44-2081-337529 (UK), or email support.info@oninit.com.
To discuss how Oninit ® can assist please call on +1-913-732-8892 or alternatively just send an email specifying your requirements.
You get all this for free.. think about what you get if you pay us