Whoa. I thought when that was leaked, that there would be no way it would be able to compile or, well, run without Microsoft's extensive and extremely complicated build setup. What an accomplishment.

I believe Microsoft's internal build toolchain was part of the leak. Looks like the particular tool used wasn't part of the centralized CI system, but rather one intended to be used to time how long builds take (guessing: intended to be run on the developer's workstation as a pre-checkin checklist step, in order to avoid committing code that bloats CI build-time?)

Heh, nope, `timebuild.pl` is the canonical entrypoint for an "official" Windows build, and has been for a very long time. It's a hideously elaborate dependency resolver and task runner that is responsible for tying together all the various build steps necessary to create an installable OS.

refs: https://web.itu.edu.tr/~dalyanda/mssecrets/other/Startup.htm

  In order to perform these operations, execute the following command from within a razzle window, whose current directory is %sdxroot%.
  ·         perl tools\timebuild.pl

  Experience with “Timebuild”, razzle, and the Windows build system

Huh. From the referenced memo:

> The complete list of depots follows [...]

> Admin, Base, COM, Drivers, DS, EndUser, InetCore, InetSrv, MultiMedia, Net, PrintScan, Root, SdkTools, Shell, TermSrv, Windows

...which bears a striking resemblance — both back then and to this day — with the root-level categories that divide up the features in the "Add or Remove Windows Features" chooser in the Control Panel.

I guess those root-level categories in the chooser (which were always pretty meaningless) turn out to represent which particular Microsoft source repo the component's code can be found in.

As a wild guess, the "Add or Remove Windows Features" chooser is the way it is, because it's the runtime representation of what's actually mostly a build-time feature selection system; where disabling a component at build time speeds up your build, at the cost of that component being forcibly greyed out in the "Add or Remove Windows Features" chooser for that build. Basically the same as disabling the building of a kernel module in a Linux modular build.

As Raymond Chen would say, "it makes sense with kernel-tinted glasses."

1. Windows developers did not build large parts of the product on any regular basis. Windows took ~18 hours to build on incredibly powerful build lab hardware -- as soon as it took longer, it was time to buy a new build lab. Incremental rebuilds were notoriously flaky, at least in the days before https://github.com/microsoft/BuildXL. The most common dev loop that I saw was to install a recent dogfood build (so APIs and binary interfaces were reasonably recent) and then repeatedly rebuild and clobber binaries on that install.

2. The only real build-configuration options for timebuild were architecture and compile mode (dbg, chk, fre, opt). There wasn't an option to build or not build parts of the tree.

3. raymondc's reference to "kernel-colored glasses" is about viewing things from the kernel side of API guarantees. This is more an applied lesson in Conway's Law.