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

Windows reference and native verification host

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.

The OptiPlex is the Windows game/build/debug/test host. Current execution is the original x86 game plus x86 adapter and x64 broker, not a rewritten native engine. Windows feature work comes first; Mac/Linux compatibility is deferred and Linux gameplay is untested. Current state records actual source/runtime versions and machine roles. Historical machine bootstrap/native-component checks below retain their recorded dates and versions.

Current operational checkpoint — October15,2026

Current API is0.2.0.dev36/ABI14/eventABI4,collegeprofile4/courtdefinition3.272Windows tests and34schema checks passed during the docs/metadata refresh, without a game launch or DLLbuild/install. Latest naturalcollegeOT/export is36ct; stable35/95saves were restored afterward. The17:12UTC read-only checkpoint found0game/0productionAPIlistener and artworkhostingalive. Old liveprocessIDs, installation paths and setup blockers below are historical.

Use the existing ssh optiplex and RustDesk loopback helper from the current MacStudio workspace. Current Macdesktopbindings must be discovered; old CUA availability is not assumed. Ghidra/JDK and build/debug toolchains run onDell; old MacWine/Ghidra paths are not resume prerequisites.

Historical access and machine setup

Current access update: RustDesk 1.5.0 console sharing is working over the existing SSH connection; mouse and keyboard input were visually verified. User-requested automatic sign-in and disabled lock-screen settings are now configured, superseding the historical no-autologon statements below. No reboot test has yet been performed. See desktop access and headless sign-in.

Use the user's existing ssh optiplex and sftp optiplex aliases from this Mac. Remote workspace: C:\Users\brent\OpenHoops. Do not copy private keys into this project or change the working SSH configuration. tools/windows/remote_ps.py transports longer scripts with SFTP and runs saved PowerShell text through an encoded loader; it does not change execution policy. Windows command-line length prevented the initial inline bootstrap; an abandoned stdin loader was stopped before any installer ran.

analysis/windows/machine-initial.json and machine-ready.json record Windows 11 Pro build 26300.9457, Dell OptiPlex Micro 7010, i5-13600T, 16 GB RAM, Intel UHD 770 driver 32.0.101.7088 and a 1 Gbps Ethernet link. Windows reports an active brent console session 1 at inspection. SSH itself runs commands in session 0. No Win32_SoundDevice entries were returned; audio availability is not established.

The SHA-256 of %ProgramData%\ssh\sshd_config before and after installation is 870a4450ca84a1ea7b57ab082d26f7b0fc2d8aef12bb4ff5d06a986c00b0e38d. sshd remains Running/Automatic. No SSH, firewall, power, autologon or RDP changes were made.

Subsequent user authorization to disable locking supersedes the no-power-change statement for that later step only. tools/windows/disable_auto_lock.ps1 changes screensaver active 1→0 and AC password-on-resume 1→0; DC remains 1. The inactivity-lock policy and Dynamic Lock values were already absent/default and were left unchanged. The registry value changed successfully; SystemParametersInfo in console session 1 confirmed the current setting is inactive. Its separate setter returned false (cause unknown), so the initial strict harness failed despite the successful disabled-state readback. The one-time task was removed after verifying that readback. Evidence: lock-before.json, power-lock-before.txt, lock-after.json, screensaver-applied.json, cleanup-screensaver-ssh.log and cleanup-screensaver-final-ssh.log. Existing lock remains: these settings do not unlock the current session or sign in after reboot. No autologon or credential changes. SSH hash remains identical.

Sources: password on resume, inactivity policy, SystemParametersInfo. To restore the inspected values, use powercfg /setacvalueindex SCHEME_CURRENT SUB_NONE CONSOLELOCK 1, reactivate the current scheme, and enable screensaver activity with SPI_SETSCREENSAVEACTIVE value 1 in the interactive user session. Original screen-saver selection and secure-setting values were not modified.

Installed toolchain and attribution

Official Microsoft sources: MSVC acquisition, Build Tools component identifiers, Windows SDK downloads, debugging tools.

tools/windows/bootstrap.ps1 installed Microsoft's stable Build Tools in C:\BuildTools with the VCTools workload, x86/x64 compilers, CMake and Windows 11 SDK 26100. Installed instance is Visual Studio Build Tools 2026 18.10.3, MSVC 19.51.36260.0, CMake 4.3.1-msvc1, Ninja 1.13.2. SDK headers are under 10.0.26100.0. Separately installed SDK component OptionId.WindowsDesktopDebuggers; both x86/x64 CDB report 10.0.26100.9457. Installer exit codes were 0; no reboot was required or performed.

Both Microsoft bootstrap executables had Valid Authenticode signatures identifying Microsoft Corporation. URLs, arguments, sizes, file versions, SHA-256, exit codes and SSH hashes are preserved in analysis/windows/bootstrap.json. Original installers remain in the remote workspace's packages directory and were copied back to local resources/research-tools/packages, with matching hashes verified. The stable URL is mutable; the receipt's recorded hash identifies what was actually run.

SDL 3.4.18 uses the previously archived source, SHA-256 9c75cf16330322c217dedd2e0609f1124f1b54b8633e763467b4684d0f4334a3. zlib 1.3.2 source is archived locally and remotely, SHA-256 bb329a0a2cd0274d05519d61c667c062e06990d72e125ee2dfa8de64f0119d16, checked against zlib's published hash. Both dependencies were built from source separately for x86 and x64. Git/Python/third-party mod installers were not needed on the Dell for this milestone.

Actual tests

tools/windows/build.cmd and prepare_build.ps1 build the existing native project using MSVC/Ninja, with separate architecture output and zlib prefixes. source-stage.json identifies every staged file and the transfer archive. Both initial builds succeeded and each passed the existing pixel CTest. PE machine headers verify seven binaries per architecture: 0x14c for x86, 0x8664 for x64.

make_parity_fixtures.py reproduces the existing 3,315 year-cell and 6,434 record-state cases. Expected output is produced by the exact hash-checked Mac binaries previously compared with original x86 code under Unicorn, rather than rerunning that historical oracle. verify_native.ps1 compares Windows output hashes after CRLF normalization. All 9,749 cases pass on each architecture, 19,498 comparisons total. This covers the six previously recovered small storage routines, not whole-engine behavior. Fixture manifest preserves provenance and exact hashes.

Both Windows pixel decoders produce the same 1,048,576 RGBA bytes for logo000.iff resource 0 as the Mac: SHA-256 52b5558420e63143c19f8187b75ca07aa6e2a842481423b7b82833571b25857f. Original input SHA-256 is d07aa47a852ea56df6374cc041cfba8513031dcd91505dab1015e5c3b9e59b88.

Temporary, triggerless scheduled tasks run bounded GUI checks in the existing console session; this does not create a remote desktop service. The first viewer run produced a valid capture but the harness lost its exit status; retaining process status with Start-Process -Wait exposed an actual nonzero exit. SDL renames main to SDL_main on Windows, so falling off the non-void function does not receive C++'s special implicit success return for main. Added explicit return 0; to the existing viewer, without changing rendering. viewer-rebuild.json supersedes the original viewer binary hashes; other binaries are unchanged. The corrected Mac Metal build also exits 0 (mac-viewer-rebuild.json).

The corrected x86 and x64 Direct3D 11 runs both exit 0 and produce identical 960×760 BMP readbacks, SHA-256 48a3e7743fb2ef24bc933741b76a0ea00fc42e746600b07437cac20fd1b4f63a. verify_render_capture.py checks the 512×512 texture rectangle against independent Pillow alpha compositing with zero channel differences. This is one DXT5 texture at 1:1 scale, not scaled sampling, whole-game graphics or all-platform parity. Evidence: console-smoke-03.json, renderer-verification.json, original BMPs and derived PNGs. Failed earlier reports remain preserved.

Reference game preparation

The original NBA2K14-extracted corpus is unchanged. A separate 7,740,323,840-byte transfer archive stages 4,907 files, substituting only the valid executable and rld.dll extracted from the user's ISO into that working copy. analysis/windows/reference-stage.json records every member's hash and the archive hash. The restored loose Crack files remain invalid-header evidence and were not used.

The working copy lives at C:\Users\brent\OpenHoops\reference-game. prepare_reference.ps1 verifies the archive and every extracted member, then extracts the two imported legacy dependencies, X3DAudio1_6.dll and xinput1_3.dll, from the supplied disc's x86 DirectX CABs. It verifies CAB hashes and PE architecture, records DLL hashes/versions/signatures, and copies them beside the game. There is no system DLL replacement or game/mod installer execution.

The bounded reference_boot.ps1 launches only the hash-pinned ISO executable, observes its window, captures only the game-owned foreground window, and stops its own process at the 110-second bound. Runtime launch results are recorded separately below. No menu/gameplay claim follows just from process survival or successful native viewer checks.

Windows launch observation

reference-boot-01/report.json confirms a responsive NBA 2K14 window at 15, 45, 90 and 110 seconds. It was never foreground; no screenshot was captured and the harness stopped the game at its bound. The 64-bit PowerShell module listing sees the WoW64 host modules and is not a complete x86 game module inventory.

reference-snapshot-02/report.json identifies foreground LockApp, explaining why the console desktop was unavailable for screen capture. PrintWindow returned true but produced an all-black image; this is not proof the game itself renders black. The first CDB command included -pd, which this environment rejected with The system does not support detach on exit, despite returning exit code 0. Required memory files were absent, so the harness correctly marked the attempt failed. The game survived and was then stopped by the harness. A follow-up removes that unnecessary option for the noninvasive read.

The snapshot uses CDB noninvasive debugging to suspend threads and read memory without a normal debugger attachment, and .writemem to preserve literal ranges. CDB options document -pv, -p, -cf and log output. No network debugger listener is configured. No Windows menu or gameplay is visually verified yet.

Working runtime-code capture

Snapshot 03 succeeded after removing -pd. CDB read 256 bytes at 0x006A8200 and 4,096 at 0x02164310, exited 0, and the game survived. The harness then stopped only its own game process. Its x86 module inventory includes D3D9 and Intel graphics modules; missing symbols and unwind warnings mean stack frames remain leads rather than verified call chains. Foreground remained LockApp; PrintWindow produced an all-black image again.

tools/windows/analyze_snapshot.py validates exact sizes, the report, full 92-byte WinMain equality with the prior Wine capture, and complete instruction coverage for the 659-byte bootstrap body 0x02164310..0x021645A2 (inclusive). All 148 instructions decode; all internal jump targets fall on instruction boundaries. Its 43 calls include a repeated application-loop candidate: at 0x0216454C, load ECX from [0x015D08F0]; at 0x02164552, call 0x004E0190; at 0x02164559, repeat while EAX is nonzero. The exit path proceeds to 0x0216455F and cleanup. These are exact static edges in captured runtime bytes, not a trace proving gameplay/frame semantics.

The target is beyond the CDB-reported nba2k14 image end 0x02146000, so it must not be translated into an ordinary file RVA or described as an unchanged original-CD function. It is runtime code from the pinned ISO variant. analysis/windows/runtime-startup.json preserves exact bytes/disassembly, branches, calls, IAT attribution and limits. Next useful capture is 0x004E0190, together with relevant initialization helpers.

All three temporary, triggerless scheduled tasks were removed after completion. analysis/windows/cleanup.json records no remaining game/CDB processes and unchanged SSH config. No recurring task, autologon or desktop-sharing service was added. Interactive game/menu checks still need an unlocked desktop and, for remote control, console-sharing access. SSH already suffices for builds, tests and this noninvasive runtime capture.

Remaining scope

Native OpenHoops has not reached the NBA 2K14 menu. The valid original executable's Mac Wine menu was user-observed, and that remains reference execution. Windows CDB now obtains startup bytes without the WineDbg attach-correlated fault. The former missing bootstrap target is captured; its repeated call to 0x004E0190 is the next concrete dependency. Full initialization, simulation and main-loop semantics remain unresolved. See game startup.