THE FINAL NIGHT

Setup runs its course

By 18 July there was, at last, nothing left to diagnose. The Service Pack 4 CD was attached; the product key had been entered by the corrected, statically verified procedure of chapter 5; the hardware corrections of chapter 6 were landing. Capture 26 cold-booted a hash-verified copy of the capture-24 disk and typed the key properly into the five auto-advancing fields. Capture 28 then did something no run had managed in the fifty-two days since the first checkpoint: it let mddosem carry a native Windows 2000 Professional SP4 GUI setup, begun from blank media, all the way to the end — with nobody stepping in.

The phase that had eaten seven weeks — Performing Final Tasks — took three hours and forty minutes. It was watched, characteristically, through the side door: twenty-one 1-bit reconstructions of VGA plane memory (the X-ray technique of chapter 5), one roughly every ten minutes from 20:16 to 23:56, each showing the hidden progress dialog a little further along.

And then the guest reset itself. Every previous reset at the end of setup had been the bad kind — the pulse through the keyboard controller that fed the restart loop of chapter 2. This one was the good kind: the scheduled final reboot with which every healthy install hands over to the operating system it has just written. The journal records that capture 28 performed its final guest reset instead of returning to the former all-Waiting wall, and the campaign moved into its last night.

The final night, minute by minute

Everything from here happened between seven minutes past midnight and half past three in the morning of Sunday 19 July. The record is unusually exact — every capture booted a hash-verified fresh copy of the disk, and every binary printed its build stamp — so the night can be replayed.

At 00:07 the installed disk booted (capture 29). Setup did not resume: the RestartSetup flag that had driven the wizard’s eternal return was finally clear. The first wrinkle came from the games menu instead — FreeCell’s first frame rendered pure black, a PNG of exactly 5,757 bytes, byte-for-byte the size of the wall screenshot that had recurred across four days of captures (chapter 4). Old ghosts. At 00:45 an eleven-megabyte VGA-register trace was pulled from the QEMU reference machine to compare rendering behaviour; what changed between the black frame and the good one is not spelled out in the record, but by 02:23 FreeCell was drawing its green felt correctly.

One last blue screen

At 01:49 the night produced its scare. Capture 38 bugchecked with STOP 0x0000007B — INACCESSIBLE_BOOT_DEVICE, the stop an NT kernel raises when it cannot reach the volume it booted from. Seventy-three minutes before the finish line, the emulator appeared to have lost the hard disk.

The run-down was brisk and, by this stage of the campaign, well drilled. The bugcheck was not a fair experiment: the runs that hit it were carrying the campaign’s own diagnostic rig — capture 43 reproduced it while paused under a kernel breakpoint at DbgBreakPointWithStatus — and clean, production-style runs with the ISO attached never reproduced it at all. Capture 45’s temporary packet-level ATAPI trace then showed a perfectly healthy drive conversation — inquiry, capacity, table of contents, READ(10) — with Windows meeting the drive’s unsupported mode pages through ordinary sense-and-retry recovery. The journal’s verdict: “No ATAPI workaround or disabled device was needed, and all temporary diagnostics were removed.” The last blue screen of the campaign was self-inflicted — the instruments, not the machine.

That A1 is IDENTIFY PACKET DEVICE: the probe was still chattering in the stderr of the victory-adjacent runs, a reminder of how thin the line between instrument and subject had become. The rest of the night is the good kind of uneventful. At 02:22 the Log On to Windows dialog appeared — Administrator, blank password (capture 42). At 02:23, green felt: “Cards Left: 0”. The release binary was rebuilt twice in the final hour, at 02:36 and 02:54 — mddosem v0.156.3, build 669806963, interpreter-only, as every run of the campaign had been. Capture 45 — the instrumented run, ATAPI probe still attached — ran the full sequence between 02:43 and 02:46: splash at 02:43, first desktop at 02:45, FreeCell at 02:46. Capture 46, from a fresh hash-verified copy with the ISO attached and a fixed diagnostic clock epoch, followed the 02:54 rebuild and ran Winlogon → Administrator login → Explorer → FreeCell → clean guest restart; its duration went unrecorded. Capture 47, from a second fresh copy with no fixed epoch, reached Winlogon and a responsive desktop between 03:00 and 03:02, and wrote desktop-settled.png. The last of the four fixes had been committed at 03:05 (chapter 6 tells that story); at 03:27 the acceptance was recorded, and MDD-BUG-KILN-00004 — raised on 30 June as “Windows 2000 GUI setup restart-loops at ‘set system security’” — was flipped to Fixed.

The desktop, settled

What does a fifty-three-day desktop look like? Unremarkable — which is the point. A maximised Search Results window idles behind (“0 object(s)”); in front, the Getting Started with Windows 2000 wizard offers to register, to discover, to connect; a line drawing of a two-button mouse explains double-clicking. A grey taskbar. A Start button. A clock.

The clocks are the human detail. The host filesystem stamped desktop-settled.png at 03:02; the guest’s taskbar says 2:04 AM. In the FreeCell frame the gap yawns wider still: green felt written at 02:46 host time, 12:04 AM on the guest taskbar. An emulated machine keeps whatever time it is told to — one acceptance run pinned the real-time clock to a fixed diagnostic epoch, the other ran with none — and neither guest quite agreed with the host about the hour. Windows, for its part, kept both clocks with perfect composure.

The acceptance checklist, as recorded

The acceptance was a checklist, not a feeling. As recorded in the bug ledger and the branch journal:

• A fresh, native GUI setup completed from blank media under the default interpreter (capture 28) — no transplanted install, no bypass, no disabled component.
• The installed disk boots without setup resuming: RestartSetup and SystemSetupInProgress cleared (captures 29–32).
• Administrator logs in with the blank password; Explorer is responsive.
• FreeCell launches and renders.
• The guest restarts cleanly.
• Two independent fresh-copy acceptance runs — capture 46 with a fixed diagnostic RTC epoch, capture 47 with none.
• Focused regressions green: the fail-first PSE regression, all 2,512 mddosem-interp tests (0 failed), formatting, clippy with warnings-as-errors, and a warning-free release build.

The validation claims are scoped, and the record is explicit about it. A broader full_test quick run was bounded at 900 seconds and timed out after sixteen per-crate suites had passed — and was deliberately not claimed as a full gate. The exact-tree final gate belongs to the integration step, and the journal says so in as many words.

What two clean boots prove — and what they don’t

They prove that the default interpreter, presented with unmodified retail media and a product key, completes a native Windows 2000 Professional SP4 installation and reaches a repeatably usable desktop — twice, from independent hash-verified fresh copies, one of them with no diagnostic clock at all. And they prove it on the campaign’s own strict terms:

What they don’t prove is just as carefully recorded. The ledger entry is Fixed, not Closed: “Codex authored the final Open-to-Fixed transition and therefore must not close it” — the two-eyes rule holds, and a different verifier must reproduce the result before the bug may be closed. MDD-BUG-KILN-00005 — whether the dynamic recompiler can carry Windows 2000 — remains open; every banner of the campaign reads interpreter-only, and the recompiler sat this story out entirely. And two boots on one machine measure repeatability, not breadth: the wider compatibility matrix is a different campaign.

The method, in four habits

If the fifty-three days have a transferable lesson, it is not about Windows.

• A standing controlled experiment. The QEMU reference install — same ISO, same key, same Standard PC HAL — completed with a zero-byte error log (chapter 1), so every divergence was, by construction, a real emulation bug. Most of the red herrings of chapter 2 died against that single fact.
• Falsifiable hypotheses, or no new tracer. After a diagnostic-dominated month, the June goal document imposed a rule — “Diagnostics serve a falsifiable hypothesis or they don’t ship” — and every slice thereafter had to end in a behavioural fix or a definitively ruled-out layer, not another trace log.
• Instrument honesty. The census misreads were retracted by the tool’s own authors (chapter 4); the “key accepted” claim was formally withdrawn and the experiment redone (chapter 5); the PIC conformance oracle was required to re-find already-fixed bugs before its word counted (chapter 3). An instrument you are not willing to indict is not an instrument.
• Hardware truth over convenience. All four unlocking fixes are statements about real silicon — what an 8254 keeps counting, what a PIIX3 reports, what STI’s shadow protects, how a four-megabyte page translates — not about Windows. That is why they were worth seven weeks: every other guest crosses the same wires.

mddosem’s own engineering rule says that when an application works, it is because the emulation is right — never the other way round. On 19 July, at 03:02, Windows 2000 agreed.

How we know

Every number on this page traces to a preserved artifact, a ledger entry, or a journal line. The anchors, as transcribed in w2k-data.js:

Sources for this chapter — the bug ledger MDD-BUG-KILN-00004 (raised 2026-06-30, Fixed 2026-07-19, closure pending under the two-eyes rule); the engineering journals, wrk_journals 2026.06.23 → 2026.07.15; the preserved run archive (47 hash-verified captures, ≈85 GiB, 15 July 16:08 → 19 July 03:02). All Windows imagery on this page is HTML/CSS recreation — the originals stay in the archive. The emulator’s own page: mddosem.