For our Heart of Darkness experiment, the useful starting point was not a complete virtual Windows machine. It was HODE, a reimplementation of the game's engine. The engine and the original game data are different things, and keeping them separate makes the setup easier to understand.
This is a bounded build note from work recorded on 14 October 2026. We re-read the source instructions and launcher for this article; we did not repeat a full gameplay test during publication.
What HODE supplies
HODE supplies an engine that reads supported original Windows demo or CD data. Its README lists files including hod.paf or supported demo alternatives, setup.dat and level-related files. Check the README and RELEASES.yaml for the source revision you use. An engine download is not a game-data download.
Use game data you are entitled to use. We are sharing the setup method, not an ISO, extracted game files or a bundled commercial game. The upstream engine is usineur/hode, a separate project created by its credited developers.
The recorded native build
The work record used source revision 59f3c466923c6b8d49e29176ff697a91165e7efc, an arm64 environment, the existing clang++ compiler and SDL2 2.32.10. The recorded build command was:
make -j4 CXX=clang++This describes that environment. It is not an instruction to install a particular old dependency today or a guarantee that every current Mac will build the same checkout without adjustment. Record your source revision and dependency versions before troubleshooting differences.
Keep data and saves separate
The engine exposes --datapath for original game files and --savepath for progress. Our launcher uses separate locations. A schematic invocation is:
hode --datapath="/path/to/owned-game-data" --savepath="/path/to/separate-saves"Replace both example paths with your own locations. The separate save destination must exist and be writable. Keep a backup of existing saves before changing engines or source revisions. The invocation shows the relationship between paths; it is not a ready-to-run command on an unconfigured machine.
A Finder launcher is a convenience layer
We added a .command file so the experiment could be started from Finder. The recorded launcher still points to a specific engine installation. That makes it useful on the test machine, but does not make it a portable application package. A distributable launcher would need clear engine-path configuration and its own testing.
What we can claim
The recorded work documents a native build and game-data loading, with later screenshots reporting a menu and an in-game scene. That is useful evidence of startup. It does not establish complete controls, sound, cinematics, save/reload behavior or completion of the game.
For a reproducible compatibility record, test startup, movement, action controls, audio, cinematics, saving, reloading and a stated duration of play separately. Mark untested rows as untested. A screenshot of a working scene should not silently stand in for all of them.
The transferable lesson is the structure of the experiment: record the engine revision, supply legitimate data separately, isolate saves, add convenience only after startup works, and describe exactly what was observed. Compare this with our Prehistorik 2 DOS demo note, which uses an emulator rather than a replacement engine.