Just Let It Flow

August 20, 2014

The Road to Windows XP – Windows Whistler Build 2202

Filed under: Road To Windows XP,Windows — adeyblue @ 12:54 am

It seems like everybody and their mother has done a Youtube video or series about the history of Windows in one way or another. Whether they focus on the evolution of a single version by pasting The Collection Book’s screenshots of the interim builds together, or show installs of every major version, they all basically zone in on one aspect, the UI/desktop. And why not, it’s the first point of contact with the product and arguably the most important part of Windows, given that it’s named after it and all.

If you’ve read any other posts here though, you’ll get the idea that I like knowing what’s going on below the surface and behind the scenes. So that’s what I’ve jumped on the bandwagon to do, look at these steps towards XP and find the stuff that other people may have overlooked. Find the series on Youtube under the Winutiae channel.

Why XP? Well, it’s just about the right size to chronicle. It doesn’t have too many files like Vista and up have, had a shortish development period with enough leaked interim bulids so that each has something new without being overwhelming, and lets face it, in the current climate, after Windows 7 it’s still the next most popular version of Windows.

Anyway, on to the first post Windows 2000 build. Whistler 2202.

Build Tag: ntvbl06.000202-1835

Download from Archive.org
Watch on Youtube:

Just about two months after the release of Windows 2000, the first tentative steps towards the next version began. The watermark text on the desktop calls this version SD Windows 2000, after “Source Depot”, Microsoft’s new code management system.

The all new Whistler 2202 desktop.

So what is there to show for these two months of work so far? Well, not much at all visually, or in any other way really. Except for the mentioned desktop string, 99.9% of the branding remains the same as a stock 2000 system. The 0.01% difference isn’t due to the single installation screen which calls it whistler, that’s apparently a fix someone made to make build 2202 installable direct from CD.

No, the 0.01% comes from one other place in the system which acknowledges this as an inauspicious start to the next coming of Windows. Where do you think it’d be? The ntoskrnl exe? Nope. How about kernel32 or ntdll, which have changed in other ways as we’ve already seen? Nope. User32? nah. Even if you listed of all the dlls you know you most likely wouldn’t get it. So where is it? Printui.dll.

Yep, among a bunch of other Windows versioning strings, there are two new additions. Only instead of showing as Windows Whistler, it shows as Windows 2001, and curiously only in the AXP64 and IA64 architectures. You can see it by installing a printer, real or virtual, then going to the properties->sharing tab and selecting Drivers for additional versions of Windows.

The first mention of Windows 2001

Even if they’re not enabled in this build, the Comments? box that appears in the Window captions can be by adding two entries to the registry. The funnily named LameButtonText which determines the actual text, and LameButtonEnabled which unsurprisingly determines whether it’s enabled or not. Then log off, log on again and viola, as the French say.

LameButtonEnabled in 2202

Getting really into nitpicky territory, more differences come from the fact that somehow little errors have creeped into various dll and exe resources. The easiest one to access is in Narrator’s extended about dialog, where a space and newline were added into sensory system’s url. So now we’ll never know how their url ends. Another similar weird change was made to a single resource string in the accessibility wizard where “key” was changed to “k ey”.

Weird added spaces in Narrator's resources

A final really minor change saw a seemingly inaccessible checkbox added in DirectShow’s DV video decoder, qdv.dll. This checkbox enabled the selected resolution of the decoded video to be saved as the default, something which wasn’t possible in Windows 2000. Seemingly inaccessible because the actual resource dialog wasn’t resized to make it visible. Luckily this dialog was used as a child dialog in WMP and the parent is sized big enough to show it.

New (hidden) checkbox in qdv.dll

Away from the nitpicky and onto the new usable functionality, because, there actually was some. Although at this stage the new functionality is really just existing private functions that’ve been exposed to the public.

The first was the interlocked list functions, though here they’re guarded by a check to see if the cpu supports cmpxchg8b. Obviously, been so close to 2000’s release, Microsoft had yet to decide that CPU support for that instruction was a requirement to run Windows. In this build, if you were running a CPU that didn’t support the instruction, they still had to make the function’s work atomic. The interlocked list functions only allowed for 8 bytes of state, so not enough for a Critical Section object. Plus they don’t have a shutdown, ‘close’, or ‘delete’ function so using the state to house an allocated pointer to one would just leak. So what did they do? They used the peb lock. I can only think that at the time they knew this was a temporary measure because as we all know, using one lock to guard two separate things rarely turns out well.

The only lockless function that has a lock - InterlockedPushEntrySList

As well as that which we’d seen before, a new component we hadn’t came in too. Nebulously described as “WDM Resource Manager” in the version information of its’ kernel mode component and the similarly undescriptive “Resource Manager User Mode” for its user mode component, it’ll be no shock that it appears to be some sort of resource manager. At least, I trust that’s what it is. Looking at the disassembly gives no clues as to what it actually does or services it provides. The user mode component, apart from leaking a critical section in DllMain, just forwards calls to the kernel mode component. Even if there wasn’t a string saying so in the code, it’s clear that whatever their job is its targeted towards multimedia and in particular the DirectX family.

The only importer of the user mode component is quartz.dll, the DirectShow runtime, presumably for use in its implementation of the IResourceManager interface (with no symbols and a thunking QueryInterface it’s hard to tell what the interface is). The kernel mode part is also statically imported, this time by win32k.sys who uses it to register ‘DDRAW_OVERLAY’ (the DirectDraw Overlay) as a resource to manage.

A patent describing what it does in painstaking detail is available on the internet, though the exemplary API towards the end is just that. The function names are the same as those exported, but the number and format of the parameters doesn’t correspond to the bits in this build.

Resource Manager components in Whistler 2202

Lastly, apart from just adding functions, Microsoft they took them away too. Shocking I know considering We think of Microsoft as one who do their best to ensure forwards, backwards, any-which-way-but-loosewards compatibility of software. Alas no, if you only developed NDIS 3 network drivers you now had some work to do to upgrade. To be fair, NDIS 3.0 was contemporary with Windows for Workgroups so it’s not like the interface had just been introduced but still, consigned to the dustbin it was. Luckily, Microsoft publicly documented this, and the document still exists on MSDN today

New and Removed NDis functions

And that would be it, as far as things worth mentioning. These are all displayed in moving technicolor in the video so if you want to see how to access or find these things, that’s your best bet. Anyway, next up will be the more interesting 2211 build, featuring among other things, a new logon screen and the first appearance of version 6 of the common controls.


  1. I don’t suppose you have access to any of these early beta builds, or specifically any of the AXP64 ones? It would be very interesting to try out the early 64bit windows builds…

    Comment by Ben — January 22, 2015 @ 8:51 pm

  2. No AXP64 ones, just the standard beta that exist on places BetaArchive and WinWorld and Mega (http://megafiles.me/s/windows-whistler).

    Comment by adeyblue — January 27, 2015 @ 12:41 am

  3. I wonder why they didn’t copy ExInterlockedPushEntrySList etc with the spinlock stuff.

    Comment by Yuhong Bao — July 27, 2017 @ 3:49 am

  4. Also reminds me of https://blogs.msdn.microsoft.com/oldnewthing/20040506-00/?p=39463/ .
    (of course, in the end Win98 ended up requiring a 486)

    Comment by Yuhong Bao — August 5, 2017 @ 4:00 am

  5. Thinking about it, I wonder about stealing a bit to be used as a spinlock using lock bts.

    Comment by Yuhong Bao — August 6, 2017 @ 3:23 am

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress