|
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.