Hundreds of millions of users worldwide assumed that the profile picture assigned during their very first Windows XP boot was chosen entirely at random. On September 9, 2026, veteran Microsoft engineer Raymond Chen posted a snippet of code, finally unlocking the system logic hidden beneath the surface for a quarter of a century. That seemingly whimsical initial picture was never a blind draw from a hat—it was the deterministic result of a precise calculation.
A Tweet Sparks Code Archaeology
On December 11, 2025, a user named Xeno asked a question on Twitter: had anyone ever attempted to figure out the RNG mechanism Windows XP used to determine user account pictures on first creation? It was an enduring mystery that had lingered across developer forums for more than twenty years. Back in April 2004, Raymond Chen had mentioned in a blog post that XP chose default pictures at random. But that brief passing comment had never satisfied hardcore developers. They did not want high-level summaries; they wanted to see the actual implementation and algorithm derivation.
Raymond Chen finally shared the underlying code logic on his blog, The Old New Thing. The post quickly surged to 333 points and 162 comments on Hacker News. Readers were fascinated to discover that whether a new installation greeted them with a guitar, a flower, a soccer ball, or a chessboard, the outcome was never plucked out of thin air. Behind the desktop was a rigorously calculated mathematical workflow.
The Seed: Locking Onto Boot Milliseconds
In Windows XP, these initial user picture files were tucked away deep in the system hierarchy: %ALLUSERSPROFILE%\Application Data\Microsoft\User Account Pictures\Default Pictures. Whenever a new user account was provisioned, the operating system had to pick an image from this directory.
The core pseudorandom number generator invoked was RtlRandomEx, a standard utility within the Windows kernel ecosystem. Every PRNG requires an initial seed. Rather than tapping into complex hardware entropy sources, Microsoft engineers simply passed the return value of GetTickCount(). This API function retrieves the exact number of milliseconds elapsed since the operating system booted.
Pseudorandom algorithms are bound to deterministic inputs. If you recorded the exact millisecond count of the machine during boot, you could mathematically predict the exact picture assigned. What felt like pure serendipity to the user was, at the code level, an entirely reproducible sequence.
Reservoir Sampling: Compressing Iteration to a Single Pass
When dealing with a directory of unknown file count, the textbook approach is a two-pass scan: first iterate through the folder to count total files, generate a random index between 1 and n, and then iterate a second time to fetch the file at that position. This is the classic naive two-pass algorithm.
Microsoft engineers took a far smarter path: a single-pass algorithm. As the system scans the directory, it maintains only two variables: a counter count and the current winner. For every entry encountered, count increments by one. The algorithm then replaces winner with the current item with probability 1/count. Once the traversal finishes, whatever file remains stored in winner becomes the final selection.
Figure: The selectRandomFromIterator single-pass algorithm code. Source: The Old New Thing
This is a textbook special case of reservoir sampling where k = 1. In a collection of n items, the last item has a strictly 1/n probability of being chosen. If it is not selected, the problem reduces recursively to choosing uniformly among the preceding n - 1 items. Regardless of how many files exist in the directory, every single image enjoys an identical 1/n probability of ending up as the winner.
Mathematical Elegance Meets File System Constraints
Why discard the straightforward two-pass scan in favor of reservoir sampling? The answer lies in the architectural bottlenecks of the operating system. During the account creation phase, file system calls incur vastly higher overhead than CPU arithmetic. Early mechanical hard drives suffered severe latency penalties when performing repeated directory traversals over collections of small files.
A single-pass traversal drastically slashed file system overhead. Furthermore, it gracefully handled directory changes during selection without throwing errors.
The naive two-pass approach demands that the directory contents remain completely static between the first pass and the second pass. If another background process added or deleted an image in that fleeting window between counting and retrieval, the system could encounter an out-of-bounds indexing error or throw a file-not-found exception. The single-pass mechanism elegantly eliminated this race condition entirely.
Stopping Hard at 100 Pictures
While reservoir sampling is mathematically elegant across arbitrary input streams—with the replacement probability scaling down proportionally as the counter climbs—production operating system code never gambles on unbounded execution. Within this core routine, engineers hardcoded a pragmatic, brute-force safety cap.
Once the algorithm has sampled 100 pictures from the iterator, it abruptly breaks out of the loop and immediately returns the current winner.
Figure: Windows XP default Luna interface. Source: Wikipedia
Frontline systems engineers do not indulge in mathematical purism. Hardcoding a physical ceiling of 100 files ensured that even if a pathological user dropped a million files into the directory, the boot sequence would never stall. Pure mathematical models demand uniform distributions across infinite sets, but industrial-grade code bears a higher duty: ensuring the operating system never hangs.
An Illusion of Serendipity Engineered to Precision
Looking back at the question on Twitter, countless people between 2001 and 2014 remember the thrill of powering on Windows XP for the first time. Seeing an orange soccer ball, a rubber ducky, or a green treefrog felt like a charming personal surprise from the machine. End users could never perceive the millisecond timing fluctuations during startup. A jitter of a few thousandths of a second masqueraded convincingly as true randomness.
Raymond Chen’s post did more than settle an old trivia question—it captured a frozen snapshot of an earlier era of software engineering. In those days, RAM was scarce, mechanical drives were slow, and every syscall had to be justified. Defensive programming guarded every corner case.
That default avatar 25 years ago was never pulled from a carnival hat. Through bounded file ceilings and reservoir sampling, it quietly orchestrated a masterclass in deterministic engineering for two generations of computer users.
References:
- The Old New Thing
- HN
- Wikipedia
