Draft:Windows build FAQ

This is a help page to deal with the common questions that people ask when dealing with Windows builds.

What's the buildstring at the bottom-right corner of the screen?
The buildstring is a way for builds to be uniquely identified. It began being used around the turn of the millennium, shortly after the transition from the Source Library Manager (SLM) version control system, used since 1986, to the Perforce-based Source Depot, in June 1999. Until late 2016 (before the reproducible builds effort), it was also embedded in the version information of all files. It takes the form:

a.a.xxxx.y.cccccccc.dddddd-dddd (a.a not displayed on desktop)

where:

An example build string: 6.2.7950.winmain_win8m2.110223-1820 Windows version 6.2 (Windows 8), build 7950, compiled in the  branch, started on February 23, 2011, at 18:20 The time is Pacific Standard TIme (PST), the timezone of Microsoft's Redmond campus, where the server farm that builds Windows is located.

Before the turn of the millennium, only a build number was used; service packs usually increment the delta, and in later versions incremented the build number by one. This is also the same for later Windows 10 versions that were not full upgrades.

How are builds found?
Since 2014, Microsoft flights builds - since 2016 typically from the  branch - to Windows Insiders on a regular, usually weekly basis, unless a release is approaching where a different branch is used. Before then, most builds came from the Ecosystem External Access Program (EEAP), or a similar beta testing programs. The EEAP is a program where builds were sent out weekly to companies that are in the Microsoft Partner Program and work on Windows drivers for their hardware, as well as Windows applications. These builds can be from a variety of branches depending on the specific needs of the partners they are being sent to. Microsoft has also historically done beta testing programs for IT professionals and the general public (Windows Me is an example of this, with weekly mailings of discs), in some cases involving millions of people (Windows Vista). These builds, as a result of their wide distribution, are far more likely to be publicly leaked. Additionally, builds can sometimes be discovered in the personal archives of ex-Microsoft employees after they leave the company, typically in the form of a burnlab disc or floppy.

Can I have ?
No, with all certainty we don't have it. Find it yourself.

What's a branch / why are some builds with higher build numbers compiled later? / Why do some builds with the same build number have different features?
Microsoft has thousands of developers working across Windows, Azure, and Xbox at any one time. If they all checked in code to the same codebase, there would be endless merge conflicts as different teams tried to merge at the same time. The OS would also be very unstable as code would be checked in as soon as it was written without being tested or integration tested to ensure it works with other components of the operating system that are also changing. To solve this, branches were introduced. To put it simply, each subteam (of around 25 developers) has their own branch, where changes specifically for their features are checked in, Then, on a schedule, each branch is reverse integrated into the mainline branch and integration tested to ensure compatibility with changes from other teams. All checkins require a code review and approval from the development lead of each team, as well as testing, before they are allowed into the build for quality control purposes.

Initially, branches were grouped by general area of Windows, and were simply numbered, with 1-7, 10, and 21 known. ("_N" suffix branches was used for reverse integration) This was used for Windows XP, Windows Server 2003, and Longhorn pre-reset. It was eventually decided that this system was too unwieldy and led to components not being sufficiently integrated, causing unstable builds and contributing to the failure of the original Longhorn project. It was then decided to create a branch for each individual team, with several levels of branch reverse integrating into each other. Although this did lead to some incredible crapfests, such as |the shutdown menu that took 24 people two years to design, it generally worked and is still used to this day. Initially this was called the VBL (virtual build lab) system, but it was later renamed to feature build lab (FBL) for Windows 7.

How is Windows built?
Each dayn compiled on a daily basis on a virtual machine on one of Microsoft's build servers, using Microsoft's propreitary Razzle build environment. Any employee can track this live using an intranet link. Building takes approximately twelve hours (building of the actual binaries and then the "postbuild" process of building an image are about half and half of this time), and then the bits (SDK, DDK, VHD, ISO) for all compiled architectures and SKUs are dumped in the branch's dedicated folder on the internal //winbuilds/ (originally called //ntbld/) network share for a certain amount of time before expiring depending on the status of the build, with some exceptions. For older versions of Windows, there was a physical room at Microsoft campus (called the "Build Lab", or the "Engine Room" for Windows 9x) where the build was assembled each day, and - for versions before Windows 8 - another room (in 2003 it was located in Building 27) where physical discs would be burned for builds that passed sufficient testing to be used internally.

How is Windows tested?
Builds from non-main labs are typically tested by the teams responsible for them.

For the main branch (currently, historically   between 2000 and 2004, followed by  ,  ,  ,   and  ) or any milestone or public release branch, if no build break (Microsoft slang for a compilation failure) has occurred during the approximately twelve-hour compile process, an SDET (software design engineer in test, Microsoft's pre-2014 term for a tester) would install and boot the OS on a machine (in the current day, most likely in a Hyper-V VM) to ensure basic functionality. This would then be followed by BVT testing, where fairly extensive stress testing with a very large variety of hardware (it is not clear if this is still done) is done to attempt to find issues caused by strange hardware configurations or edge cases, as well as stress testing every component of the operating system for several hours in order to ensure quality. If this passes, it is marked as TST (or, in modern parlance, pushed out to the Canary ring), where Windows developers that have opted in then install it and develop using it. This is the practice of "eating your own dog food", or dogfooding for short, where the operating system is developed on itself as it develops. This is intended to force the developers to fix bugs that they are experiencing, instead of ignoring them as they are not affected by them.

For older versions of Windows (before Windows 7), additionally stable builds could be declared "IDW" (internal developer workstation), implying that they were safe to be used for development, and more stable builds "IDS" (internal developer server), implying that they were stable enough to be used for hosting internal servers, or released to the aforementioned EEAP or one of its predecessors. These days, builds from the Insider branches are flighted weekly if they are stable enough for general public use and are deemed stable enough during their times in the Canary and Dev Internal channels.

How is a Windows version developed?
While no two Windows versions have identical development patterns owing to the unpredictable nature of software development, all NT versions up to Windows 10 generally followed a similar development methodology.

Before Windows 10
At the start of the project, usually several months or even years before the completion of the previous version, planning for the version begins. This was usually when the codename is created. As the previous version approached completion, more detailed plans, team charts, and in some cases even early development work would be started. After the previous version was completed, development would progress along a series of milestones. These were specific dates by which certain levels of completion must be reached - early versions instead called these "development releases", or had a more traditional "Alpha" stage). After the final milestone was completed, work would then commence towards a sometimes relatively feature-complete (Windows 7 build 7000, sometimes extremely not feature complete (Windows 2000 build 1671, Windows XP build 2296, Windows Vista build 5112), "beta" version, and "beta" versions would be released until the product was essentially feature complete. Then the release candidate phase would commence, which mostly focused on tweaking the user experience, fixing bugs, and making any final changes. After several release candidates, a branch would be created for RTM, and final stabilisation work would commence. Eventually, some build would be declared RTM (21 days without any showstopper bugs reported was the requirement in the mid-2000s) and sent off for manufacturing. By the time it was available in stores to buy ("general availability"), further updates to fix bug would be released.

Windows 10 and later
Windows 10 scraps the concept of a rigid 3 to 4 year development cycle to instead focus on semesters, which are worked on in parallel and are designed to deliver features quickly (originally six-months, but extended to one year in 2022 with Nickel). Semesters initially had their own codenames, but they were later changed when the Windows and Azure groups were merged. Milestones are still internally used for each semester, but there is no beta or release candidate as such. Major changes can occur to the product between RTM and GA, as was the case with the Cobalt semester. Typically a new semester is started when the previous one branches for RTM (creating the *_release branch).

What version control system does Microsoft use?
Before February 1986, Microsoft used |Berkeley SCCS, the first ever version control system. After this, they moved to an internally developed clone of |RCS called SLM (Source Library Manager). The source code to this version control system is available in the 782 and NT4 source, and a binary is available in the original Xbox OS source code. It did not support branching and tracked only single files, a lá CVS. This made it unsuitable for large projects.

In 1999, due to the Windows 2000 project showing that over 1,500 developers checking into primarily (branches existed but required manual copy of the entire Windows source code, which was several gigabytes in size at the time) a single tree was not feasible, Microsoft forked Perforce and renamed it Source Depot, continuing to add features such as a GUI for changes and increased ability to handle very large projects. This greatly benefited development as it supported branching and many other features SLM was not architecturally capable of handling. This solution sufficed until 2017, when the number of branches reached a point where Source Depot was struggling to handle the size of the Windows project - branch creation took several days. This prompted Microsoft to move to Git, which was completed for most teams in late 2017 with the creation of the "OS" repo. However, even Git is not large enough to handle the size of the Windows project (over 500 GB in code and assets by 2018), and a new repo is created approximately every three years to avoid hitting Git theoretical limits and no longer allowing push. The current repo is OS.2020.

You may notice that neither Microsoft Delta, Visual SourceSafe, or Microsoft Team Foundation Server, Microsoft's publicly available version control solutions, were ever used internally. This tells you all you need to know about their quality, especially the former two.

Do any Windows versions have source code leaked?
Yes. Windows NT 3.5 RC2, Windows NT 4.0 SP1, and most of (enough to get a working build with some workarounds) Windows XP SP1 and Windows Server 2003, as well as the original Xbox OS and ~2005 Live source.

What virtualisation software should I use?
If you are running classic Windows (Windows 1.x-3.x or 9x), or specific [|NT builds] then you should really use |86box or a similar product, which emulates systems in lieu of virtualising them using a hypervisor and is therefore more accurate to the quirks of these early builds, as well as having more configuration capabilities. Usually, these early builds will boot in hypervisors, but there will be bugs that would not occur in emulator. For "modern" builds (Windows XP and later), they are usually happy to be booted in a hypervisor, but you may need to use compatibility settings or older versions of the products to get specific features working. Your mileage may vary, check the BetaWiki page for the build you're trying to test before installing. Remember, this is pre-release software and can therefore be unstable or do things you would not expect.

My ISO won't boot!
Some ISOs are not bootable. For versions before Windows Longhorn, you will need a bootdisk. If there is no bootdisk provided, use a bootdisk from Windows 98SE and use that to run setup. For classic Windows, find  and run it. For NT-based Windows, find  and run that. This is not supported for Windows Longhorn build 3683 and later ("Windows Longhorn 2004" apparently should not be run with "DOS 1985" :P). For these versions, check the BetaWiki page of the build you are testing for instructions.

How do I run Windows on ARM without an ARM machine?
You can try to boot it on QEMU, but some will not work or have missing drivers; there are workarounds for this, but you will have to consult the BetaWiki page for the build you are trying to install.

Timebomb information
Microsoft did not want these builds being used after the testing period was up. This was first implemented in Korean Windows 3.1, but it was not used generally until Windows 2000 and Neptune. The OS will either fail to login, fail to boot with a BSOD, or turn off various functionality such as personalisation. This is not related to Windows Activation. Some builds can be debombed, but I will not provide instructions on how to do this.

Windows 1.x - does pre-DR5 exist?
The short answer is yes, there are at least two versions confirmed to exist. The long answer is good luck getting it.

Windows 2.x - why are there no beta builds?
Because none of them have been found yet.

Windows 95 - General protection error on boot
This is caused by having a CPU faster than 2.1 GHz. It can be fixed by using an emulator, underclocking your CPU with a frequency below 2.1 GHz, or using the |FIX95CPU patch.

Earlier versions of Windows - hard drive size limited to 137.4 GB
This is a driver limitation - the hard disk driver installed on the OS does not implement 48-bit LBA, which means that the hard drive capacity is limited to the 28-bit LBA limit of 137.4 GB. With all likelihood, this cannot be resolved unless an OS update is installed.

Windows 2000 - Reboot during last stage of setup
This is a timing bug in later builds of Windows 2000, including the final build. To fix it, use 86box or a similar emulator to workaround the timing bug, or click really fast. I'm serious, this causes the OS to be busy processing events and for some reason causes the bug not to trigger.

Windows 8 - there are missing features in the screenshots / where is Metro?
If you are running a build before 7814, it's not there. If you are running a later build, it's because Microsoft didn't want you to see it. Thankfully, some clever folks have managed to get around their attempts. The protection system is called Redpill, and you can read more about it there if you wish. The primary tool to unlock features is [Redlock]], which can be downloaded at its page and run.

Windows 7 - I can't find some features!
Microsoft also didn't want you to find features in Windows 7, but Windows 7's lockdown system was substantially weaker than Windows 8, and was bypassed in 2008 by the original BlueBadge tool, before being improved in 2020 with the Bluepill tool - it can be found |here.