Cesarus85--mjolnir-vr/docs/object_matching_logs/thread_win32_obj.md

thread_win32.obj exact-match strategy ledger

Scope and required toolchain

• Translation unit: source/bungie_net/common/thread_win32.c
• Target: January 2002 thread_win32.obj
• Compiler: XDK 3911 CL 13.00.9254.1
• Flags: /O2 /Oy- /DDEBUG /Dxbox
• Strict gate: tools/coff_compare.py and whole-object data/ownership checks
• Detailed historical analysis: CREATE_THREAD_TIE_ANALYSIS.md

Current validated baseline

Seven of nine functions are strict exact:

Function	Target/base size	Target/base relocs	Result
code_0006fc30	48/48	2/2	exact
code_0006fc60	64/64	3/3	code bytes exact; strict relocation-owner alias differs
create_thread	240/240	14/14	nonexact; one underlying NULL-store codegen site
thread_has_exited	80/80	5/5	exact
dispose_thread	112/112	9/9	exact
create_mutex	144/144	10/10	exact
take_mutex	96/96	5/5	exact
release_mutex	64/64	5/5	exact
dispose_mutex	112/112	9/9	exact

_bss_0031c728 is a defined, exact 1,544-byte BSS section. The current source uses = { 0 } deliberately so the symbol belongs to this translation unit instead of becoming a COMMON symbol.

code_0006fc60 residual

The normalized code hash, size, and relocation count are identical. The only strict difference is the one-past mutex-array relocation:

• target: _bss_0031cd30 + 36
• candidate: _bss_0031c728 + 1580

Both resolve to the same address, but the strict comparator conservatively refuses the ownership/alias mismatch. No exact credit is claimed.

create_thread residual

The target and candidate are identical through offset 0xD9. The sole underlying difference is the priority/resume-failure output store:

target:    xor eax,eax; mov [ebx],eax
candidate: mov dword ptr [ebx],0

The two-byte encoding-length difference shifts the following epilogue bytes. All 14 relocation identities remain exact.

Accepted source controls

• A distinct unsigned long thread_id local preserves the measured January register allocation around CreateThread.
• _ReadWriteBarrier() immediately after the inlined reference allocator is a zero-byte compiler intrinsic that preserves the January join topology.
• The function, assertions, API calls, priority mapping, return behavior, and preserved slot-leak bugs are reconstructed and documented in source.
• create_mutex uses a single-result/shared-write source shape that is strict exact and serves as the two-live-value NULL-output donor.

Rejected or exhausted source families

Approximately 180 measured legal-C variants are catalogued in CREATE_THREAD_TIE_ANALYSIS.md. Do not repeat them. They include:

• single-write, split-write, nested, ternary, goto, and multi-return layouts;
• all tested placements of _ReadWriteBarrier, _ReadBarrier, and _WriteBarrier;
• 24 declaration orders, register, value-copy, output-local, and thread-ID spellings;
• inlined allocator loop rewrites; and
• diagnostic pragma/flag probes, none retained.

Two additional forced-inline helper families were measured on 2026-07-28:

Experiment	Target/base size	Relocs	Base normalized hash	Outcome
forced-inline helper couples output store and boolean return	240/240	14/14	f6340b3e...00341	byte-identical to baseline; rejected
forced-inline void helper performs only the output store	240/240	14/14	f6340b3e...00341	byte-identical to baseline; rejected

Both experiments were fully reverted; the tracked source hashes exactly to HEAD afterward.

Provenance and compiler audit

• Every locally present XDK compiler set examined has the same hashes for C1.dll, C1xx.dll, C2.dll, and CL.Exe; no alternate local QFE exists.
• The HCEA prototype PDB contains create_thread with parameters flags, function, function_input, and thread_reference, plus the local unused_thread_id. This corroborates the source lineage and local role.
• The later HCEA body is not a January donor: it stores the selected reference immediately after CreateThread and does not clear the output on the priority/resume failure path.
• No public or local exact C donor with the full three-live-pointer plus register-zero NULL-output topology has been found.

The remaining compiler-QFE explanation is therefore unproven. The accurate classification is an exhausted compiler register/materialization tie under current source knowledge, not proof of a different compiler binary.

Do-not-repeat list

• Do not retry barrier placement, declaration permutations, shared/split output writes, ternaries, goto layouts, register, allocator-loop rewrites, or inline output helpers.
• Do not use inline assembly, volatile byte forcing, undefined behavior, object-byte patches, or compiler-flag changes.
• Do not transplant the later HCEA control flow as January-authoritative.
• Do not accept the code_0006fc60 address-equivalent relocation alias as strict exact without a separately reviewed ownership rule.

Reopen criteria

Reopen only if at least one of these appears:

1. January source/debug provenance reveals a genuinely new control-flow or declaration topology.
2. A strict-exact donor has three live pointer-like values and a distinct register-zero NULL-output exit.
3. A different authentic Bungie-era 13.00.9254 compiler binary improves the unchanged source.
4. A newly demonstrated legal-C control is not represented in the exhausted matrix above.
5. A conservative, general COFF ownership proof can equate the code_0006fc60 relocation aliases without admitting false positives.

Current disposition

The reconstructed checkpoint is valuable and buildable, but thread_win32.obj is not complete and must not be marked Matching. Park the two residuals with this ledger until a reopen criterion is satisfied.