Hash-matched binary conversion profiles

Live compatibility layers (Wine, Proton, and similar) reinterpret foreign ABIs at runtime. That is a powerful compatibility strategy. It is not the only one.

A complementary systems strategy: treat a lawfully held foreign binary as input to a hash-matched conversion profile, write a host-native (or host-shaped) cache on disk, and run the cache. Distribute the recipe, not the converted game — unless the rights holder ships the converted artifact.

HCI Nerdz owns the human symptom (on-disk game conversion). DevCentr owns the systems altitude and points at adaptation substrate (equivalence-engine, binary-tailor).

Why live translation is not the only wire

Mode Characteristic

Live translation

Foreign binary remains the object; every launch pays ABI/API translation; shared runtime improves many titles at once

On-disk conversion

Foreign binary is feedstock; profile keyed by content hash; converted tree is a cache; per-title analysis cost amortized across launches and users

Publisher native / port

Best wire when available — no community reverse-engineering required

Hubs should encode a vendor source priority list:

  1. Native Linux (or host) builds from the vendor.

  2. Publisher-authorized ported binaries.

  3. Original build + applicable conversion profile (local apply or vendor-hosted cache).

Profile as the distributable unit

A conversion profile should:

  • Bind to content hashes (and explicit version metadata) of candidate files.

  • Describe transforms at a chosen altitude: relocation/import rewrite, block patches, IR-level recompile plans, asset endian/path fixes — whatever the title needs.

  • Prefer metadata and mapping over embedding large slices of the original binary (reduces “we shipped the game” failure mode; does not magically clear all IP questions).

  • Support verify → apply → cache → run, with rollback to the original tree.

flowchart TD
  Store[Store / hub priority]
  Native[Native host build]
  Port[Authorized port]
  Orig[Original foreign build]
  Prof[Hash-matched profile]
  Cache[On-disk converted cache]
  Run[Launch cache]

  Store --> Native
  Store --> Port
  Store --> Orig
  Orig --> Prof
  Prof --> Cache
  Native --> Run
  Port --> Run
  Cache --> Run

Relationship to existing DevCentr substrate

  • equivalence-engine — natural home for rulesets and shortest-path mappings across implementations; a game conversion profile is a specialized rules / DAG artifact keyed by hash.

  • binary-tailor — different job (polyglot pack → host PE/ELF/Mach-O after delivery), same reshape bytes on disk after you already have them instinct.

  • PackageHub / install coordinators — candidates to wrap recognized installers so post-install conversion is a delivery step, not a forum ritual.

Binary weaving (partial conversion)

Do not assume every byte must be decompiled and re-emitted. A conversion profile can weave a runnable image from:

  • Leave-alone segments — same-ISA machine code and data that never touch a foreign ABI (pure compute, many game loops, assets already portable).

  • Rewritten boundaries — imports, loaders, TLS/SEH glue, path/endian fixes, calling-convention edges.

  • Replaced modules — whole subsystems swapped for host-native equivalents (the DXVK / native-audio pattern), with thinner shims at the cut.

Prior art at coarser altitudes: Proton-style component replacement; at finer altitudes: hybrid ABIs such as Arm64EC (foreign and host code in one process with thunks at crossings).

When weaving helps

Same-ISA Win→Linux is mostly link/load/import surgery, not a full ISA rewrite. Leaving compute intact is less work and less runtime cost than universal IR recompile. Module-level native replacements remove whole call-volume from the foreign ABI.

When weaving hurts

Thunks at every tiny boundary add overhead and complexity. Dual runtimes (half Wine, half converted) without a clear cut plane are usually worse than one coherent strategy. Cross-ISA titles need real translation for leave-alone code anyway.

Heuristic

weave at the coarsest cut that removes most ABI tax (DLL/module first, function second, basic-block last). Full recompile is a last resort for hostile or ISA-mismatched regions — not the default architecture.

DRM / kernel anti-cheat remain out of scope for early wedges; they already constrain live-translation stacks. This page does not claim to solve them.

Near-term proof

Two complementary proofs — do not conflate them.

Toy spike (machinery)

A spike = short, throwaway-friendly experiment to prove the pipeline, not a polished commercial port.

Toy title = a tiny Windows PE you (or the project) authored — e.g. console “hello” or a MessageBox — whose hash you control.

Minimum bar:

  1. Build the toy PE (Windows).

  2. Author a hash-matched profile (coarse weaving: leave compute; rewrite load/imports/glue).

  3. Apply → on-disk host-shaped cache → run on Linux.

  4. Version the profile in git; keep the original PE for verify/rollback.

Oracle title (quality)

After the pipeline works, use a game the publisher already ships on Windows and Linux (Valve/Steam first-party titles are the obvious candidates when you own both depots).

  • Input: the Windows build you lawfully hold.

  • Oracle: the official Linux build of the same title (ideally same app/depot generation).

  • Goal: behavioral and structural comparison — does the converted cache play/load like the native Linux build? Which modules stayed leave-alone? Where did Valve’s port diverge from a mechanical PE→host weave?

This is not expecting bit-identical binaries. Official Linux builds use different toolchains, packaging, and sometimes different code paths. The oracle answers “are we in the right ballpark?” and “what did a real port change that a weaver must learn?” — not “diff -r must be empty.”

Keep both depots local (lemonade bottle). Do not redistribute converted trees or Steam depots as the test artifact; publish profiles and methodology notes only.

Optional docs face: short walkthrough of toy spike and/or oracle comparison. Learning goal is machinery + quality confidence, not marketing before/after art.

Hard walls (systems honesty)

  • Full automated decompile → perfect native recompile is not a general algorithm; titles need profile authorship (human + AI + tooling), not a universal shredder.

  • DRM and anti-cheat that require Windows kernel trust will reject or ban converted stacks regardless of elegance — defer rather than center the roadmap.

  • Installer porting is a separate, harder problem than converting the post-install game tree.

Legal posture (systems face — not counsel)

This page is architecture literature, not legal advice.

Clean ladder (preferred → contested):

  1. Publisher ships native, port, or authorized profile/cache.

  2. User applies a community or hub profile locally to copies they may already run; hub does not redistribute game binaries.

  3. Redistributing converted games, or profiles that primarily smuggle copyrighted payload / defeat DRM, lands in familiar copyright and anti-circumvention territory.

Local “lemonade bottle” framing: the user owns the copy instance on their machine and may transform it locally; that is not an argument for store-scale redistribution of converted trees. Contract (EULA), copyright, and anti-circumvention regimes still apply and vary by jurisdiction — design for the clean ladder; document gray zones without pretending they are green.

Sibling faces

Face Where

HCI symptom / treatment

HCI Nerdz concept On-disk game conversion (docs topic on-disk-game-conversion)

Product seed

dev-centr/project-plans — seeds/2026-09-03 - on-disk-game-conversion.md

Related delivery instinct

Binary Tailor

Related