Oninit Phoenix Recover

Because the reconstruction process is best appreciated by seeing the results firsthand, it can be difficult to demonstrate effectively with a simple example or screenshot alone. The easiest way to understand what the tool can do is to upload a compiled program and let it process it for you.

Simply upload an Informix 4GL compiled program (.4ge) file, and the tool will analyze the binary and reconstruct readable .4gl source. The decompiler recovers the module's functions and their call graph; control flow including IF/ELSE, WHILE, CASE / WHEN, FOR and FOREACH with their EXIT / CONTINUE statements; MENU, INPUT and CONSTRUCT interaction blocks with their per-key ON KEY sections; REPORT definitions including the procedural code inside each FORMAT section; embedded SQL and cursor operations; expressions, function calls with their RETURNING targets; and the variable definitions it can resolve — making it easier to inspect, document, maintain, or migrate legacy applications when the original source is no longer available.

Recovery works on not-stripped programs — the ordinary output of c4gl. As a deliberate policy the tool refuses stripped binaries, whose symbols have been removed; it is intended for recovering your own builds, not for reading programs whose authors chose to strip them. Uploads are limited to a single not-stripped program of up to 100 KiB.

A compiled program is normally linked from several source modules together with the GLOBALS files they share, and the compiled form keeps no record of which module each routine came from. The recovery therefore returns everything the program contains as a single .4gl source — every module and the global declarations combined in one file, which for a substantial program can be large. The content is complete; it is the original division into separate files that cannot be recovered, so the recovered source is a starting point for re-splitting into modules rather than a like-for-like replacement of the original file set.

Recovery currently supports Linux builds only — 64-bit x86 programs as produced by c4gl on Linux. A program compiled for another platform uses a different executable format and instruction set, so it cannot be read by this release even when it is not stripped. Support for further platforms is under consideration; if you have compiled programs on another Unix and need them recovered, please get in touch.

Single-file uploads are supported, and once processing is complete, the reconstructed .4gl source is rendered directly on the page for immediate review. No additional software, configuration, or manual extraction steps are required.

How we verify recovery, not just claim it

A decompiler is easy to demo and hard to trust, so we don't just show a plausible-looking result — we compile it. Every recovered .4gl is checked against the original, unmodified 4GL source the compiled program was built from, then handed to the real, unmodified IBM Informix 4GL compiler to confirm the recovered source is genuinely valid 4GL — not merely readable, but re-compilable. Both checks run automatically, on every change to the recovery engine, against a reference program built from public, non-customer 4GL source.

The verification checks four independent things against the known-correct original: the recovered program's function inventory (every routine present, none invented), its call graph (which routine calls which), its embedded SQL (the static DELETE/INSERT/UPDATE operations the program issues), and its statement-type coverage (the mix of 4GL verbs — DISPLAY, FETCH, CURSOR, control flow, and the rest — the recovered source actually contains). The current reference run: 14/14 functions recovered, 17/17 call-graph edges, 3/3 static SQL operations, 8/8 statement verbs — then a clean compile against the real compiler with zero errors.

Here is a short excerpt, side by side: the original hand-written source on the left, what the recovery engine reconstructs from the compiled binary alone (no source, no debug symbols) on the right. Recovered stack-local names (p_1) and cursor identifiers (cursor_1) are synthetic — a compiled binary keeps no record of the programmer's original local-variable or cursor names — but the logic, the SQL, the control flow, and every field reference reconstruct exactly.

FUNCTION getrow(l_currpos)

    DEFINE l_currpos INTEGER

    FETCH ABSOLUTE l_currpos rwd_cur INTO m_current_rowid
    OPEN table_cur USING m_current_rowid
    FETCH table_cur INTO
        m_current.id,
        m_current.name,
        m_current.desc,
        m_current.cmd,
        m_current.dest,
        m_current.active
    IF STATUS = NOTFOUND THEN
        MESSAGE " Recently Deleted"
        CALL init_buf()
        SLEEP 1
    ELSE
        DISPLAY BY NAME m_current.id
        DISPLAY BY NAME m_current.name
        DISPLAY BY NAME m_current.desc
        DISPLAY BY NAME m_current.cmd
        DISPLAY BY NAME m_current.dest
        DISPLAY BY NAME m_current.active
    END IF
    CLOSE table_cur

    MESSAGE ""

END FUNCTION

FUNCTION getrow(p_1)

    DEFINE p_1 INTEGER

    FETCH ABSOLUTE p_1 cursor_3 INTO m_current_rowid
    OPEN cursor_1 USING m_current_rowid
    FETCH cursor_1 INTO m_current.*
    IF STATUS = NOTFOUND THEN
        MESSAGE " Recently Deleted"
        CALL init_buf()
        SLEEP 1
    ELSE
        DISPLAY BY NAME m_current.id
        DISPLAY BY NAME m_current.name
        DISPLAY BY NAME m_current.desc
        DISPLAY BY NAME m_current.cmd
        DISPLAY BY NAME m_current.dest
        DISPLAY BY NAME m_current.active
    END IF
    CLOSE cursor_1
    MESSAGE ""
END FUNCTION

(This reference program's original source and its identifiers are already public — a small stand-alone maintenance utility used only as our verification baseline. Real customer programs recovered through this feature are never used as examples here.)

The decompiler runs server-side; nothing is stored. Some fine detail cannot be recovered from a compiled binary — un-named stack locals appear as synthetic names, and a few pure-data statements leave no trace — so the reconstructed source is intended for reading and re-authoring, not as a byte-for-byte round trip. See also the companion form decompiler, Oninit Phoenix Forms.