Native Runtime Architecture

The binaries behind Director MX 2004 and Shockwave - Dirapi.dll, Iml32.dll, Proj.dll - plus the reverse-engineering methodology and evidence standards used in this section.

What this section is#

The pages under Native Internals document original reverse-engineering research into the Director MX 2004 / Shockwave native runtime, conducted with Ghidra against the retail binaries. Where the manuals describe what an API does, these pages record how the engine actually implements it: symbol tables, property descriptors, dispatch routes, compositor callbacks, and presentation logic.

Function names are Ghidra-style addresses (FUN_680c8c3e = function at that virtual address in Dirapi.dll). They are stable identifiers for the analyzed binaries, not official names.

Evidence levels#

Every claim in this section carries an implicit strength grade:

Rule of thumb: native code and microtests outrank guesses, other emulators' behavior, and AI review. A table slot proves a name exists; only tracing the consumer proves what it does.

The binaries#

Division of labor, as recovered:

• Proj.dll parses projector settings, creates the stage window through IML32, and drives the runtime through a small set of Dirapi ordinals (idle pump, status readback, window rebinding).
• Dirapi.dll owns everything scripting-visible: the symbol/descriptor machinery (Native Lingo internals), channels and their dirty flags, event routes.
• Iml32.dll owns pixels and windows: rect helpers, DIB/palette Windows API usage, the final per-pixel compositor callback families (Native rendering).

Methodology#

The workflow that produced these findings, reusable for further research:

1. Define the question in Director terms (e.g. "what does ink 8 do to 4-bit sources?").
2. String probe: locate API name strings and their addresses in the target binary.
3. Table probe: follow references to those strings; Director API names sit in dense pointer tables, and the table neighborhood reveals the API family grouping.
4. Decompile the consumers: never decompile a data table slot itself; find the code that reads the table and decompile that.
5. Registry/descriptor dumps: for scripting symbols, decode the registrar call sites to get symbol ID -> descriptor pointer mappings (arguments often travel through callee-saved registers, so instruction-context dumps are the ground truth for missing immediates).
6. Classify and trace: descriptor first-word distributions, branch classification in the shared executor, callback family mapping.
7. Microtest: build a minimal fixture movie in real Director that exercises exactly one behavior, and log/compare.

Headless Ghidra automation ran each step; probe outputs (Markdown + JSON) are kept as evidence artifacts separate from conclusions, and conclusions link back to the artifact and address ranges.

Failure modes to avoid#

Documented mistakes from this research, so others skip them:

• Treating a table slot as code: decompiling data produces garbage; failure to decompile does not mean "no behavior".
• Assuming neighboring names share a handler: table adjacency is organizational, not semantic.
• Treating a string reference as the implementation: the reference is usually a registry row; the implementation is behind a dispatcher.
• Trusting a fan emulator as ground truth: emulators encode their authors' guesses; verify against native code or a real runtime.
• Row number = symbol ID assumptions: Director's symbol interner reuses IDs for duplicate names, so table position and ID diverge after the first duplicate (details in Native Lingo internals).
• Changing runtime behavior in an emulator before the native owner is known: symptom-level patches (per-room, per-window offsets) always regress somewhere else.

Map of the findings#