What algorithm did Windows XP use to choose your initial user picture?

Post by unregistereddev » Thu, Sep 10, 2026, 2:44 PM UTC

agumonkey wrote: post #34

mrweasel wrote: post #12

Earlier quoted context omitted.

That's a matter of taste, but for many it was the Windows they used first and/or spend the most time on and there's a lot of love for that reason alone. I never used XP all that much, but I always changed the theme to the Windows 2000 look. I really didn't like the default, it looked unprofessional and clunky in my eyes. Upon release XP was also pretty universally mocked as a Fisher Price-like UI. To me Windows 95/NT…

win2k was peak for me. lean, functional, just a pinch of glitter here and there (short fade-ins). it was on par with the amazing stability brought by nt5 kernel. i kinda miss xp at a cultural level since it was a bit the end of that computing culture cycle (after that apple started to dominate and ubuiquitous computing influenced desktop ui)

Post by layer8 » Thu, Sep 10, 2026, 2:48 PM UTC

rhplus wrote: post #111

scrumper wrote: post #91

This is a fun example of the cognitive switch you have to employ when first starting to program a computer. It's extremely easy for a human to pick at random one thing from a pile of things: you reach out your hand and grab it, maybe swirling them around on the table first to shuffle the order. For a computer, there's no direct analogy to that. They just can't do it. And the human process is nothing even slightly lik…

I think this article highlights more the importance of understanding system limits in the 1990s versus today. No-one would care to much today if the code review for this feature had “files.count()” or whatever in it, but in the mid 90s that would have been a huge performance red flag because a user would literally hear their hard drive clicking away and see the blinkenlights.

Post by ulrikrasmussen » Thu, Sep 10, 2026, 3:04 PM UTC

wongarsu wrote: post #104

ulrikrasmussen wrote: post #94

But the naive way of doing this also wouldn't really require two passes, right? It would just require more memory because you would first save all file names in an array (stopping at 100), then pick a random one in constant time.

How do you know how big your array has to be in a single pass? I don't think the WinXP source uses vectors or similarly ergonomic auto-growing arrays. You could preallocate an array big enough for 100 paths of length MAX_PATH, but that's a bit wasteful. And it doesn't sound like you'd actually end up with fewer lines of code (in that flavor of C++, in python it would be different)

Post by cloudfudge » Thu, Sep 10, 2026, 3:15 PM UTC

lyorig wrote: post #27

Man, every post from Raymond Chen regarding Windows internals is like a little Xmas. I wonder whether he has to ask someone for permission before publishing this knowledge, though.

Post by madibo3156 » Thu, Sep 10, 2026, 3:40 PM UTC

layer8 wrote: post #114

rhplus wrote: post #111

Earlier quoted context omitted.

I think this article highlights more the importance of understanding system limits in the 1990s versus today. No-one would care to much today if the code review for this feature had “files.count()” or whatever in it, but in the mid 90s that would have been a huge performance red flag because a user would literally hear their hard drive clicking away and see the blinkenlights.

The problem isn’t counting the files (the algorithm in the article also counts the files), but that if you determine that you want to use the i th file only after counting all files, you have to iterate over the whole directory again (or over expected half of it) to find that file.