Diablo II Shareware demo

Package and installer

The local package is Blizzard's DiabloIIDemo.exe:

• size: 138,309,685 bytes
• SHA-256: 89352716523e474514553e2092a1ae9349c5c7ff9e79c7861dd65fe19be88b61

test/test-diablo2-demo-installer.js drives setup without fixed-batch dialog timing. It waits for Diablo II Shareware Setup, clicks the launcher's Install button, waits for each real InstallShield control, accepts the default path, and reaches the shortcut/copy phase. A full acceptance run continued through the 127 MiB copy. The worker finished after about 205 seconds; the outer setup window remained on Adding shortcuts to the start menu.., but the complete installed payload was present in the VFS. The retained acceptance screenshot is /private/tmp/diablo2-installer-complete.png.

Saving that VFS exposed a host-export collision: setup creates both the file C:\support\images\msproxy and descendants below a directory with that name. lib/vfs-export.js now preserves the file as msproxy.__vfs_file__ rather than failing the whole export. test/test-vfs-export.js pins that behavior.

The installer-produced payload is staged locally under test/binaries/candidates/diablo-2-demo-installer/installed-extracted/. Its core pins are:

Registry evidence

The raw captures remain under /private/tmp and are not corpus fixtures. Relative to a clean profile, setup wrote:

• HKCU\Software\Battle.net\Configuration, Server List = exodus.battle.net
• HKLM\SOFTWARE\Battle.net\Configuration, Server List = exodus.battle.net

A clean installed-game launch reaches the menu without pre-seeding either key. The game itself creates HKCU\Software\Blizzard Entertainment\Diablo II Shareware with:

• CmdLine = ii.exe -skiptobnet
• InstallPath = C:\
• UseCmdLine = DWORD 0

It also probes CompressedData and preference values, but none is required to launch this package.

Compatibility fixes

The installed executable and its DLL graph exposed three concrete gaps:

1. CRTDLL _vsnprintf was missing. The bounded formatter now returns -1 without a terminator on truncation, matching the Win9x CRT contract.
2. D2Sound imports authentic Win98 DSOUND ordinals 1 and 2. They now resolve to DirectSoundCreate and DirectSoundEnumerateA.
3. The original 64-entry synchronization table filled during startup. Storm's later transient CreateEventA returned NULL, so a one-byte MPQ member (data\local\use) reported ERROR_HANDLE_EOF and the game stopped in Archive.cpp line 143. A 256-entry diagnostic build showed startup fill every slot through e00ff; the final 512-entry/8 KiB table leaves space for the fixed pool and streaming events. The same run then read all MPQs, initialized DirectDraw and sound, and rendered the main menu.

The final installer-produced game screenshot is /private/tmp/diablo2-installed-sync512.png: an 800x600 DirectDraw frame with the animated Diablo II logo, Single Player button, Shareware v1.04 label and Exit Diablo II button. test/test-diablo2-demo-installed.js reproduces this from a clean profile, skips the intro with normal keyboard input, pins the EXE/data archives, and validates those menu regions.

One non-fatal diagnostic remains: the loader's first bounded D2CMP DllMain pass reports an incomplete return and the game's recovery path logs an SMemReAlloc() message before normal initialization repeats successfully. It is not present in the rendered game UI and does not prevent the menu or MPQ streaming, but it is the next cleanup target if DLL initialization is made fully resumable.

Character creation and gameplay

The installed demo originally crashed immediately after confirming a new Barbarian. A normal-input trace (Single Player, double-click Barbarian, focus the name field, type TEST, press Enter) stopped at batch 588 in two adjacent CRTDLL imports:

1. strncmp(0x01e4face, 0x009facf4, 10) jumped through 0x009c4d7e to the fail-fast unimplemented handler.
2. After implementing that function, _strnicmp(0x01e4f898, 0x005cb3a4, 0x7fffffff) did the same through 0x009c4d78.

Both are now real cdecl handlers: strncmp compares unsigned bytes and both functions stop at the first difference, a shared NUL, or the requested count; _strnicmp additionally folds ASCII A-Z. Zero count returns equality without dereferencing either pointer. test/test-strncmp.js pins those edge cases and the cdecl ABI.

With both imports present, the same input sequence clears the animated Act I loading portal and reaches the playable Rogue Encampment at batch 1600 with a one-million-block batch budget. The retained frame is /private/tmp/d2world-1600.png; it contains the Barbarian and NPC, rain, torches, terrain, belt and skill bar, plus the red life and blue mana orbs. A ground click later scrolls the world to the wagon without a trap; that frame is /private/tmp/d2world-2200.png. test/test-diablo2-demo-gameplay.js reproduces hero creation from --app=diablo2_demo and asserts the rendered terrain and HUD color regions, not merely process survival.

Performance and SIMD

The playable trace is CPU-emulation bound rather than blocked on an obvious host-side subsystem. Over 400 seconds it made 1,754,049 Win32 API calls (about 4.4K/s), while the interpreter recorded three active cooperative guest threads, 17,089,938 block decodes, 46,860 live-cache evictions and 1,672 full cache clears. The page's DirectDraw path already coalesces dirty presentation to at most one upload per animation frame. No API, audio, timer, networking or surface-upload storm was identified.

The cache-clear pressure came from fixed reservation rather than typical compiled size. The old allocator reserved 16KB for every compiled 4KB guest page; a fixed-allocator sample of 795 Diablo II pages found a 2,411-byte mean, with 78.1% fitting in 4KB, 97.1% in 8KB and 99.5% in 12KB. Compiled pages now use 4/8/12/16KB classes, grow only when emitted code requires it, and recycle safely retired chunks. A directory clock also makes the separate 128-index limit explicit instead of refusing all later pages. On the final replay through batch 1660 this reduced full resets to 13; the fixed-size trace recorded 128 resets during batches 1500–1600 alone and 1,672 by batch 2300. Because the host load varied substantially, this establishes the cache-pressure improvement but is not presented as a wall-clock FPS measurement.

MMX is advertised and implemented, with packed operations lowered to WebAssembly SIMD, but this run retired exactly zero MMX instructions. Static SIMD clusters exist in ijl11.dll, binkw32.dll and smackw32.dll; the active game and DirectDraw renderer DLLs contain no credible SIMD routine. The main EXE's three isolated SSE-looking byte sequences are low-confidence scan coincidences, SSE is not advertised, and no SSE path executes. Implementing more SIMD is therefore unlikely to be the first-order gameplay speedup for this shareware build; interpreter/cache/thread efficiency is the measured target.

Gameplay hot-loop census

A post-cache gameplay histogram over batches 1500..1660 mapped runtime block entries back through each PE's load delta and then checked every hot backward edge in disassembly. The table groups blocks belonging to the same loop nest; top entries is the hottest constituent block, not a sum or an instruction count. This avoids double-counting nested loops.

Smaller measured backedges (hottest block 20K–53K) are the same classes, not a new dominant idiom: more clipped d2gfx CEL variants (0x86d0da..0x86d4d5), D2CMP state/color transforms (0x652851..0x65294c, 0x653f8f..0x65408b), EXE object/list traversals (0x421274..0x4212c1, 0x4300d6..0x43049c, 0x494b22..0x49514e), short memory scans/fills (0x41fd7e..0x41fda6, 0x4c9e2e..0x4c9e45), and two short coordinate loops at 0x4dea38 and 0x4deae2. Most contain calls, pointer chasing, multiple branches, or fixed two-dimensional control and are not safe LUT_RUN shapes.

Generalized H418 LUT_RUN removes both genuinely hot byte-translation self-loops: d2gfx runtime 0x86e24e and d2cmp runtime 0x655762. In the same 160-batch main window it reduced handlers from 262,313,891 to 257,258,415 (1.93%) while processing 1,381,859 pixels. The remaining first-order local target was the straight-line/unrolled d2gfx family, especially 0x86c141..0x86c2e2; it needed an unrolled-LUT recognizer, not broader self-loop recognition.

H431 now handles that fixed-span form at decode time. It recognizes the exact descending one-source suffix and symbolically validates MSVC's scheduled two-source blend suffix, then continues into the ordinary outer row tail. On a full replay of the same batches 1500..1660, main handlers fell again from 257,258,415 to 179,778,066: 77,480,349 fewer, or 30.12% beyond H418 alone (31.46% from the original pre-LUT 262,313,891). The d2gfx suffix landings no longer appear in the hot-block top twenty; the jump-table and row-head blocks at 0x86c167, 0x86c141, 0x86c38e and 0x86c34d remain, as expected, because H431 is nonterminal and does not absorb their control flow. The batch 1652 Rogue Encampment capture remained healthy: terrain 87,447, life orb 3,612, mana orb 2,910 and 187 quantized colors. Host load forced the replay to its 320-second cap exactly at batch 1680, so this is an instruction-count result, not a wall-time/FPS claim.

The clipped two-source inner loop at runtime 0x86e3ca (d2gfx original 0x100033ca) now uses H418 as well. Descriptor version one adds a second advancing byte stream, an auxiliary low-byte register, an absolute table displacement and a selector for which source cursor terminates the run. A separate exact recognizer proves the observed xor/xor, two loads, shl 8, three increments, 64KB blend lookup, store and cmp source2,bound / jb order; the executor remains the shared universal LUT kernel.

In a fresh batches-1500..1660 profile, 0x86e3ca fell from the prior capture's 251,520 per-pixel block entries to 26,522 budget resumptions. H418 processed 1,205,355 pixels in 96,689 aggregate runs, while the new canonical ESP load-run recognition drove H408 2,869,328 times and removed H343 -> H343 from the top pairs. That fresh scene retired 145,589,954 main handlers and scored terrain 102,464, life 3,612, mana 2,910 and 189 colors. Its terrain workload differs from the earlier H431 capture and host load exceeded 80, so neither the total handler difference nor wall time is presented as an isolated speed percentage.

High-level meaning of the post-LUT hot blocks

The remaining block heads are easier to understand as engine operations than as instruction pairs. Counts in this table are correlated entries within loop nests and therefore must not be added together.

H431 processed 11,825,842 fixed-span pixels in 718,737 invocations in this capture. Dividing the two fixed-tile row-head counts by their 15-row shape gives about 40.8K full-tile equivalents, only as a scale estimate because clipping and variant dispatch make it non-exact. The important consequence is that H431 has already removed most pixel-by-pixel dispatch, so the remaining d2gfx cost is increasingly row setup, diamond-shape jump dispatch and function control.

That changes the next optimization level. An exact full-tile handler covering the fixed-shade and per-pixel-light variants could consume all 15 rows per call and subsume H431 internally. Separate candidates are the room collision-mask query, the fixed 8x8 light-grid builder and the signed D2CMP command decoder. Those are whole engine primitives; generic XOR -> LOAD8 or CMP -> Jcc fusions would only shave pieces of all four.

Browser CPU attribution of pixels versus row control

A subsequent Chrome/V8 sampling profile measured actual Rogue Encampment gameplay rather than inferring native cost from handler counts. The driver did not arm the handler histogram during the CPU window, moved the Barbarian with a ground click, and rejected the sample until the rendered frame contained green terrain plus both life and mana orbs. It then took a separate short histogram window in the same live instance. Two headless runs captured 46,462 samples over 15.53s and 34,918 samples over 10.49s. A state-aware intro driver then repeated the measurement in a real headful/compositor-backed Chrome window: 38,251 samples over 10.43s. Host load was still high (roughly 8--14), so these are CPU self-time shares only, not FPS or throughput measurements.

The result narrows the multi-row claim considerably:

Separating samples whose ancestry goes through thread-manager.js puts H431 at 1.82--2.21% of main-path CPU and H418 at 0.36--0.42%; neither ran on the worker path. Main-thread $next alone was 20.15--21.53%. The worker share varied from 10.7% to 18.3% in these three windows, so the earlier larger blue HUD share is phase-dependent rather than a fixed split.

The matched histogram explains what remains around H431. In the repeat window, the fixed-shade row head ran 134,596 times and the per-pixel-lit row head 122,360 times, while H431 ran 265,541 times in total. Accounting for the existing ESP load-run fusion, the two fixed-tile outer bodies represent about 5.84M row-setup/control handler dispatches out of 62.86M total (about 9.3%); including their H431 calls makes the theoretical handler-count ceiling about 9.7%. A multi-row handler would not remove the pixel work or all address calculation, however. At uniform dispatch cost it saves only about two points of total CPU from $next; direct WAT row setup could save some additional generic-handler cost. Consequently the honest expected ceiling is a few percent until an A/B prototype measures it, not evidence that the outer tile loop dominates the whole browser.

Per-present guest-operation attribution

A temporary guest-EIP range timer measured the main instance between actual DirectDraw presents. The steady Rogue Encampment window contains 57 frames; menus, loading and the first loading-to-gameplay spike are excluded. A matched empty-range control retained the frame/timer hooks but removed all hot-range transitions. The detailed probe raised median active main-guest time from 77.96ms to 89.04ms (14.2%), so uncorrected probe time is not an honest browser frame-time result. A standalone Wasm-to-JS timer-import calibration measured 85.7--92.4ns per transition; the full launch made 4.04M transitions.

The table reports exclusive loop-body buckets. “Adjusted” divides the raw medians and p90s by the measured 1.142 probe inflation. It is a deterministic Node/V8 CLI estimate of computation per DirectDraw present, not browser wall time, and helpers outside a listed EIP range remain in other.

Thus the larger named buckets are now ranked per present, but these numbers do not prove inclusive whole-function cost or transfer directly to browser milliseconds. The lower-overhead Chrome sampling result above remains the browser authority: $next is 22.44% of total CPU while H431 and H418 themselves are only 1.97% and 0.32%. The operation timer says where the surrounding guest work is concentrated; it does not overturn that native attribution.

Cooperative workers and real browser threads

The browser HUD's blue threads phase is literal wall time spent in ThreadManager.runBudgeted, but the name does not mean Web Workers. The three guest worker WASM instances currently run synchronously and round-robin on the browser's main JavaScript thread. A sequential per-instance histogram over batches 1500..1650 found:

T2's hottest nests are Storm runtime 0x9a1f40..0x9a21b3 (original 0x6ffbbf40..0x6ffbc1b3, Huffman bit refill/tree traversal; 433,747 entries in its hottest block) and 0x9a2d30..0x9a2e9f (original 0x6ffbcd30..0x6ffbce9f, ADPCM code expansion and predictor/step-index clamps; 432,499). Its secondary loops build/walk the decode trees at 0x9a1c40..0x9a1e6e and perform smaller output transforms at 0x9a31a6..0x9a31f4. Neither is LUT_RUN, and no worker instance executed H418 during the full replay.

Consequently, real Web Workers should materially improve browser responsiveness for this workload: nearly the entire blue phase could overlap the main guest instead of blocking input and paint. At the sampled rates main averaged about 1.61M handlers/batch and T2 1.13M; perfect independent overlap would put a rough upper bound near 1.7x for their combined CPU phase. That is a ceiling, not an FPS forecast: main sometimes waits for worker events, host imports such as audio/window/storage need a main-thread broker, shared emulator allocators still need locking, and the green d2gfx renderer remains single-threaded. The existing shared WASM memory, per-thread instances, atomic wait table and partitioned decode caches provide useful groundwork; the missing broker and race audit are the implementation cost documented in docs/design-real-threads.md.

Isolated-Worker bounded MPQ waits

The isolated browser backend originally omitted the bounded-wait poll floor already used by the cooperative main scheduler. Its guest clock can advance past Storm's 255ms MPQ completion wait after only one or two concurrent Worker slices. resolveMainWorkerWait() then returned WAIT_TIMEOUT while the Storm decompression worker was still runnable; Storm accepted the resulting short read, and D2CMP later reported Codec.cpp line 1563, top >= 0, while decoding the incomplete data.

ThreadManager.resolveWait() now requires both elapsed guest time and up to the same bounded number of scheduler polls while an isolated main thread still has runnable guest workers. A signal remains immediate, and a permanently unsignalled finite wait still times out after the poll ceiling. The focused regression advances the guest clock by 1000ms during a 255ms wait, proves it does not complete after the second Worker slice, then signals the event and proves normal completion.