Windows Longhorn and the Worst Code I've Ever Seen: Dave Cutler

Context and timeline

• Longhorn was the consumer (workstation) effort that eventually evolved into Vista.
• After Windows 2000, Microsoft split a previously unified server/workstation codebase into two tracks:
  • Chris Jones led the workstation (consumer) track (Longhorn).
  • Dave Thompson led the server track.
• The split made the consumer branch fragile (harder to build and run), while the server branch received many security fixes.

Security and code-quality consequences

• Windows XP shipped from the diverged consumer track. It was successful commercially but suffered many security and bug issues.
• The XP problems prompted a major, company-wide focus on security (described as addressing the “buffer overflow tax”).
• Dave Cutler’s group fixed thousands of security bugs in XP (roughly 5,000 fixes cited).
• Some legacy components were extremely poor quality and effectively unfixable; for example, an IME implementation done by a team in Japan had overflow issues that could only be mitigated rather than fully corrected.

x64 (AMD64) initiative and engineering approach

• An unofficial project to port Windows to AMD’s 64-bit extensions ran alongside Longhorn.
• AMD proposed a minimally intrusive 64-bit design that could run 32-bit applications at native speed.
• The team used the server codebase as the basis for the 64‑bit port, building both a 64‑bit workstation and server.
• Porting strategy emphasized backward compatibility and minimal changes:
  • Many 32‑bit components ran unchanged.
  • Example: Task Manager only needed a marker to distinguish 64‑bit vs 32‑bit processes rather than a rewrite.
• They developed a simulator called “Sim” to exercise setup; simulated setups were long-running (simulated setup could take ~24 hours).

First hardware boot and deployment

• When AMD hardware arrived, the team booted the 64‑bit OS directly from CD and it ran reliably.
• The 64‑bit server proved much more reliable in practice because many applications on 32‑bit systems leaked memory and exhausted virtual memory.
• microsoft.com switched to the 64‑bit server deployment after observing substantially higher reliability.

Organizational outcome

• The team unified the codebase by switching Longhorn’s codebase to the x64/server-based codebase.
• The unified x64 codebase became the forward-looking basis for the product.
• The 64‑bit effort was temporarily paused while XP security fixes were applied, but porting and integration continued afterward.

Tools and notable features

• Sim — setup simulator used for long-running simulated installs.
• AMD64 compatibility — ability to run 32‑bit applications at near-native speed on 64‑bit hardware.
• Minimal-touch porting — small targeted changes (for example, marking 64‑bit processes) instead of large rewrites.

Lessons and analysis

• Splitting a codebase for divergent goals can cause one branch to stagnate and miss critical fixes, with real security and quality costs.
• A well-designed 64‑bit ISA combined with careful OS engineering can improve robustness (fewer memory exhaustion issues) without breaking legacy applications.
• Merging divergent branches can require large bug-fix efforts; some legacy code may be so poor that only mitigation is possible rather than full remediation.

Splitting for different product goals can increase fragility and technical debt; thoughtful ISA and OS design can reclaim reliability without sacrificing compatibility.

Main speakers and sources

• Dave Cutler — primary speaker recounting Windows 2000 → XP → Longhorn/x64 history.
• Other individuals and groups mentioned: Chris Jones (workstation lead), Dave Thompson (server lead), Rob Short, AMD (hardware partner), “Al” (Cutler’s boss responsible for Longhorn), and microsoft.com operations.