← Home · Reverse Engineering · Static Analysis · Compilers

StormC / StormC++ — Reverse Engineering Field Manual

Overview

StormC (by Haage & Partner, 1996–2000) was a native Amiga IDE with integrated C and C++ compiler. It occupies a unique position in Amiga RE: it's the only native Amiga compiler with full C++ support (exceptions, RTTI, STL), yet its C++ ABI is incompatible with GCC's C++ ABI — StormC uses its own name mangling, vtable layout, and exception handling mechanism. For the RE practitioner, StormC binaries look like SAS/C at the C level (A5 frame pointer, absolute strings) but diverge significantly when C++ constructs appear.

Key constraints: - A5 frame pointer — StormC follows the SAS/C convention (LINK A5, #-N), making C-level code appear SAS/C-compatible. - C++ ABI is unique — StormC's name mangling, vtable layout, RTTI, and exception handling differ from both GCC and the Itanium C++ ABI. StormC++ libraries cannot link with GCC C++ code. - Native IDE integration — StormC embeds project metadata (source paths, build configs) in the binary via custom HUNK_DEBUG entries. - PowerPC support (v3+) — StormC 3.0+ could target PPC (WarpOS/PowerUP). PPC code sections use a different hunk type and appear as foreign code in 68k disassembly. - Hunk names: CODE, DATA (Amiga standard, SAS/C-compatible)

graph TB
    subgraph "Source (.c / .cpp)"
        SRC["C/C++ source"]
    end
    subgraph "StormC IDE"
        IDE["Project Manager"]
        EDITOR["GUI Editor"]
        COMPILER["StormC Compiler"]
        LINKER["StormLink"]
    end
    subgraph "Binary Output"
        HUNK["Amiga HUNK executable"]
        CODE["CODE hunk — 68k code"]
        PPC["PPC_CODE (optional, v3+)"]
        SYMBOL["HUNK_SYMBOL — StormC mangled names"]
        DEBUG["HUNK_DEBUG — project metadata + line info"]
    end

    SRC --> IDE
    IDE --> COMPILER --> LINKER
    LINKER --> HUNK
    HUNK --> CODE & PPC
    HUNK --> SYMBOL & DEBUG

Binary Identification

C-Level Code (SAS/C-Compatible)

At the C level, StormC output is deliberately SAS/C-compatible:

; StormC C function (looks identical to SAS/C):
_my_c_function:
    LINK    A5, #-$10               ; A5 frame pointer
    MOVEM.L D2-D7/A2-A4, -(SP)     ; 9-reg save — same as SAS/C
    ; ... function body ...
    MOVEM.L (SP)+, D2-D7/A2-A4
    UNLK    A5
    RTS

How to distinguish from SAS/C: Without symbols, C-level StormC code is nearly indistinguishable from SAS/C. Look for: 1. Project metadata in HUNK_DEBUG — StormC embeds source file paths and project names 2. StormC-specific startup code — different library open sequence 3. C++ markers — if you see C++ constructs with non-GCC mangling, it's StormC

C++ Level — Where StormC Diverges

StormC++ uses its own ABI:

; StormC++ virtual method dispatch (different from GCC!):
    MOVEA.L obj_ptr(FP), A0         ; A0 = object pointer
    MOVE.L  (A0), D0                ; D0 = vtable pointer (at offset +$00)
    MOVEA.L D0, A1
    JSR     $XX(A1)                 ; call virtual method at vtable[XX]
; No offset_to_top, no RTTI pointer before vtable!

Name Mangling — StormC vs GCC

Construct	StormC++ Mangled	GCC 2.95.x Mangled
`Window::Draw()`	`Draw__6Window`	`Draw__6Window` — can be identical for simple cases
`Window::SetPos(int,int)`	`SetPos__6WindowFii`	`SetPos__6Windowii` (no `F`)
`operator new(unsigned long)`	`__nw__FUl`	`__nw__FUl` (may match)
Constructor	`__ct__6Window`	`__6Window` (GCC uses different prefix)
Destructor	`__dt__6Window`	`__6Window` (GCC encodes in vtable entry type)

Key disambiguator: StormC prepends __ct__ and __dt__ to constructor/destructor names. GCC encodes the constructor/destructor type in the vtable offset, not the name.

Vtable Layout Differences

GCC 2.95.x vtable layout:            StormC++ vtable layout:
┌──────────────────────┐            ┌──────────────────────┐
│ offset_to_top = 0    │ vtable[-2] │ (no offset_to_top)   │
├──────────────────────┤            ├──────────────────────┤
│ RTTI pointer         │ vtable[-1] │ (RTTI pointer or 0)  │
├──────────────────────┤ ← vptr     ├──────────────────────┤ ← vptr
│ virtual destructor   │ vtable[0]  │ first virtual method │ vtable[0]
├──────────────────────┤            ├──────────────────────┤
│ virtual method 1     │ vtable[1]  │ second virtual meth  │ vtable[1]
├──────────────────────┤            ├──────────────────────┤
│ ...                  │            │ ...                  │
└──────────────────────┘            └──────────────────────┘

[!WARNING] StormC++ vtables start at the first virtual function. There is no offset_to_top field at vtable[-2]. If your struct layout assumes the GCC layout, all vtable offsets will be wrong by 2 entries.

Library Call Patterns

StormC uses SAS/C-compatible library calls:

    MOVEA.L _DOSBase, A6           ; load from global
    MOVE.L  filename, D1
    MOVE.L  #MODE_OLDFILE, D2
    JSR     -$1E(A6)               ; Open()

The difference is in how _DOSBase is initialized — StormC's startup code may use different symbol naming or library open order.

C++ Exception Handling

StormC 3.0+ supports C++ exceptions with a custom unwinding mechanism:

; Exception handling setup (simplified):
    ; StormC registers an exception handler frame on the stack:
    PEA     .exception_handler      ; handler address
    MOVE.L  ___current_exception_frame, -(SP)
    MOVE.L  SP, ___current_exception_frame

    ; ... try block code ...

    ; Cleanup on normal exit:
    MOVE.L  (SP)+, ___current_exception_frame
    ADDQ.L  #4, SP                  ; discard handler

.exception_handler:
    ; Exception recovery code

This is structurally different from GCC's exception handling (which uses DWARF2 unwinding tables or setjmp/longjmp). In the binary, look for a global ___current_exception_frame variable being pushed/popped in functions with try/catch blocks.

Startup Code

StormC's startup differs from SAS/C c.o:

; StormC startup (typical pattern):
_start:
    MOVEA.L 4.W, A6                ; SysBase
    MOVE.L  A6, ___SysBase

    ; StormC may use different library open order:
    JSR     ___OpenStormCLibs       ; open DOS, Intuition, etc.

    ; C++ static constructors (if C++ code present):
    JSR     ___init_cpp             ; calls __ct__ functions

    ; Call main()
    BSR     _main

    ; C++ static destructors:
    JSR     ___exit_cpp             ; calls __dt__ functions

    ; Cleanup
    JSR     ___CloseStormCLibs
    MOVE.L  D0, ___ReturnCode
    RTS

Same C Function — StormC Output

; CountWords() — StormC 4.0, C mode, -O2:
; (Structurally identical to SAS/C — StormC's C codegen mirrors SAS/C)

_CountWords:
    LINK    A5, #-$08
    MOVEM.L D2-D3, -(SP)

    MOVEQ   #0, D2                  ; count
    MOVEQ   #0, D3                  ; in_word

    MOVEA.L $08(A5), A0             ; str (arg1 at A5+8)

    BRA.S   .loop_test

.loop_body:
    MOVEQ   #' ', D0
    CMP.B   (A0), D0
    BEQ.S   .not_word
    MOVEQ   #'\t', D0
    CMP.B   (A0), D0
    BEQ.S   .not_word
    MOVEQ   #'\n', D0
    CMP.B   (A0), D0
    BEQ.S   .not_word

    TST.B   D3
    BNE.S   .next_char
    ADDQ.L  #1, D2
    MOVEQ   #1, D3
    BRA.S   .next_char

.not_word:
    MOVEQ   #0, D3

.next_char:
    ADDQ.L  #1, A0

.loop_test:
    TST.B   (A0)
    BNE.S   .loop_body

    MOVE.L  D2, D0
    MOVEM.L (SP)+, D2-D3
    UNLK    A5
    RTS

Named Antipatterns

"The GCC-C++ Assumption" — Using GCC Vtable Layout on StormC++

Applying GCC vtable offsets to StormC++ binaries will misidentify every virtual method by 2 slots and miss offset_to_top. Always determine the C++ compiler BEFORE applying vtable layout assumptions.

"The StormC-C++ Silence" — Missing C++ in What Looks Like C

StormC C code looks identical to SAS/C. But if the binary was compiled with StormC++ (C++ mode), global constructors run before main(), exceptions unwind, and objects have vtables — all invisible at the C codegen level. Check HUNK_SYMBOL for __ct__ and __dt__ prefixes.

Pitfalls & Common Mistakes

1. Linking StormC++ Objects with GCC Code

StormC++ and GCC C++ share NO ABI compatibility. Name mangling, vtable layout, RTTI, and exception handling all differ. If you're patching a binary and need to add C++ code, you must use the same compiler that produced the original.

2. PowerPC Code Sections (StormC 3+)

; In the HUNK structure, PPC code appears as a separate hunk type:
; If your disassembler only handles HUNK_CODE ($03E9), PPC sections
; will appear as unknown hunk types. StormC PPC sections use custom
; hunk types for WarpOS/PowerUP code.

Use Cases

Software Known to Be StormC-Compiled

Application	Version	Notes
AmigaWriter	StormC 3/4	Word processor with C++ document model
Various MUI applications	StormC 3+	MUI class wizard generated C++ classes
WarpOS/PowerUP software	StormC 3+	Mixed 68k/PPC binaries — check for PPC hunk sections
Late-era Amiga games	StormC 3/4	C++ game engines with 68k-optimized inner loops

Historical Context

StormC arrived at a pivotal moment: the Amiga market had shrunk, SAS/C was abandoned after 6.58, and developers wanted a modern IDE. Haage & Partner (known for AmigaOS 3.5/3.9) positioned StormC as the future of native Amiga development. It offered features no other native compiler had: a GUI debugger, C++ with exceptions, PowerPC support, and integrated MUI class generation.

However, the PowerPC era fragmented quickly (WarpOS vs PowerUP), the Amiga market collapsed, and Haage & Partner ceased operations. StormC 4.0 was the last release. Today, GCC (cross-compilation) and VBCC dominate, but StormC binaries remain in the wild — particularly late-1998 to 2000 era C++ applications.

Modern Analogies

StormC Concept	Modern Equivalent
Native IDE with built-in compiler	Xcode with Clang, Visual Studio with MSVC
Proprietary C++ ABI	MSVC's C++ ABI (incompatible with Itanium/GCC ABI)
Mixed 68k/PPC binaries	Universal Binaries (Intel + ARM) on macOS
MUI class generation wizard	Qt Creator's class wizard, Visual Studio's MFC wizard

FPGA / Emulation Impact

PowerPC sections: If the binary contains PPC hunk sections (StormC 3+), a 68k-only FPGA core cannot execute them — a PowerPC emulation layer (like WarpOS emulation in WinUAE) is required.
C++ exception handling: StormC's custom exception mechanism uses a linked list of exception frames on the stack — the 68000 core must support MOVE.L SP, An correctly (standard ISA support, no issues).

FAQ

Q: How do I tell StormC from SAS/C if both use LINK A5? A: Check HUNK_SYMBOL — SAS/C uses _name with =APS stabs; StormC uses __ct__/__dt__ prefixes for C++. Check HUNK_DEBUG for project metadata strings (StormC embeds source paths). Check startup code — StormC's ___OpenStormCLibs vs SAS/C's _OpenLibraries.

Q: Can I link StormC objects with SAS/C objects? A: For C-only code, possibly yes if the calling conventions match. For C++ code, absolutely not — the ABIs are incompatible.

Q: Does StormC support __saveds? A: Yes — StormC supports SAS/C calling convention keywords for compatibility: __saveds, __stdargs, __reg, __interrupt.

References

13_toolchain/stormc.md — StormC usage and features
compiler_fingerprints.md — Quick identification
cpp_vtables_reversing.md — C++ vtable layouts (GCC focus — StormC differences noted)
See also: sasc.md, gcc.md — compare with other compilers