Dated source reference. Current release status: handoff state. Full original relative paths are in the developer archive.

Application-side startup and loading-loop evidence

Historical supporting milestone. Runtime/build observations, paths and next-step statements below belong to their recorded source/date. They are not a current native-engine objective or current machine-installation inventory. Use current state, plan and API verification for active work; original research evidence remains unchanged.

Current scope (October13,2026): Windows-first deep editing and a public extension API; Mac/Linux compatibility follows later. Earlier native-port goals and next-step proposals in this evidence history are superseded. Technical observations and verification limits remain as recorded.

October 12, 2026; original EXE SHA-256 becdfca16a88f656bc20dde608bd38becf0b8e04bf41c8041d344e37d20e1d67. All addresses are preferred VAs at base 0x00400000. This is static inspection of the preserved executable, not execution beyond its SecuROM failure.

The graphics initializer now has a continuous static path through worker setup, window creation followed by device creation. Tracing frame submission upward also identifies a loading-animation update/render loop. It is not the full application or gameplay loop: original RTTI resolves that ambiguity. No game/menu or native-engine boot has been verified.

Graphics startup order

Within graphics initializer 0x00DDC6B0, the already established worker/object setup precedes these calls:

1. Copy 0x64 bytes of settings and call 0x00DDAE30 with that temporary settings block.
2. At 0x00DDC8CA, call window helper 0x00DDBE70. If it returns zero, write failure value 1 to context +4 and return.
3. At 0x00DDC8E3, call device helper 0x00DDBF30.
4. Further setup follows; adapter enumeration 0x00DDC650 is called at 0x00DDC907.

The window helper checks whether context +0xC already has a window. If zero, it constructs a stack work record with index 3, submits it to 0x00E0E860, and waits through 0x00E0BDC0. It stores the graphics object's resulting +0x850 HWND in context +0xC. It then obtains a display DC and tests device capabilities. Ghidra's GetDC/GetDeviceCaps argument grouping is incorrect; the instructions place 0x26 as the capability index and check mask 0x100. Do not infer a successfully created window from the presence of these calls.

The device helper increments global state +4 and runs the initialization path only when the old signed count is less than one. It constructs/submits/waits on index 5, then constructs/submits/waits on index 7, followed by 0x00DDABA0. Prior evidence connects index 5 to interface/device creation; index 7's full reconfiguration behavior and the final helper remain unresolved. This establishes ordered submissions, not successful initialization under every error path.

Frame submission leads into a loading loop

0x00DDA8E0 finalizes work bookkeeping and calls queue submission at 0x00DDAA14, passing the existing work record from a context's +0x2C. It does not assign that record's operation index here; do not claim that this instruction alone proves index 8. Two readable callers are independently confirmed by Ghidra:

0x00AB51D0 subsequently calls 0x00AB4D20 at 0x00AB52EA. Both invoke callbacks through the object held at 0x01349810. They pair 0x00DDBC50 with 0x00DDA8E0 around additional work. The game's top-level entry, full main loop, simulation semantics and menu state machine are still not recovered.

The global object's factory at 0x00AB3070 reads selector 0x01349808, subtracts 2, bounds-checks against 25, and dispatches through 26 entries at 0x00AB340C. Constructor vtable stores lead to original MSVC RTTI for 17 LOADING_ANIMATION classes:

Selectors 6 and 9 route to the return-only default entry; out-of-range values also return through the default branch. The table gives the factory's selector mapping, not a list of externally selectable modes or evidence that every class is exercised. FIRSTRUN is a useful first-launch lead, not proof that it is the main menu.

This corrects the initial broader “application loop” hypothesis: its instantiated callback classes identify this particular repeated rendering path as loading animation. Treating it as the whole engine's main loop would give a misleading reconstruction target.

Evidence and historical next step

Recovery script locks the original hash, checks file-backed bounds, exports nine complete instruction ranges, walks all factory entries, and preserves each constructor prefix/vtable/RTTI chain. It confirms four call references against an independent read-only Ghidra export. Structured evidence includes exact bytes, addresses, versions and script hash; Ghidra export includes twelve selected functions and twenty references. Project changes were discarded. These checks establish static structure, not native or original-game behavioral parity.

.venv/bin/python tools/recover_application_boot.py

Two higher callers of loading setup are raw branch leads at 0x009F115B and 0x009F2DCB, locally decoded inside candidates 0x009F1120 and 0x009F2D30. Their complete roles are not verified. A naive “last pair of INT3 bytes” search initially pointed before 0x009F2D30; a single INT3 at 0x009F2D2F separates the actual local prologue. Do not use padding heuristics as authoritative function ownership.

The historical next step was obtaining the supplied alternate executable and a working reference launch. The Windows working copy now runs. Use these startup findings only for a concrete deep-editing integration question; the current API/external-mode plan supersedes further native boot reconstruction.