https://betawiki.net/api.php?action=feedcontributions&user=2.204.223.225&feedformat=atomBetaWiki - User contributions [en]2024-03-28T21:18:45ZUser contributionsMediaWiki 1.39.6https://betawiki.net/index.php?title=Internet_Explorer_4&diff=212405Internet Explorer 42022-05-15T23:27:44Z<p>2.204.223.225: /* List of known builds */</p>
<hr />
<div>{{ Infobox Internet Explorer<br />
|version = 4.0<br />
|image = InternetExplorer4.png<br />
|releasedate = 1997-09<br />
|about = InternetExplorer4About.png<br />
}}<br />
'''Internet Explorer 4''' is a version of [[Internet Explorer]], released in October 1997 for Windows and 6 January 1998 for Mac OS. It can run on [[Windows 3.1]], 95, 98, NT 3.51, NT 4.0, [[Mac OS 7.1]]+, and [[Solaris]]. Installing Internet Explorer 4 on [[Windows 95]] or [[Windows NT 4.0]] gave users an option to enable the 'Windows Desktop Update', which adds Internet Explorer integration to various parts of the OS. This includes replacing the traditional Windows Explorer with a web browser-like interface, and Internet-enabling the desktop itself via [[Active Desktop]] (which includes the infamous 'channel bar' of advertising links). Internet Explorer 4 shipped with [[Windows 95 build 1216|Windows 95 OSR 2.5]], [[Windows NT 4.0 Terminal Server Edition]] (4.01, albeit being an optional install and without Windows Desktop Update) and [[Windows 98]] (4.01 SP1) and was later released for Macintosh.<br />
<br />
This version also updates parts of the logo branding, using the well-known "e" icon introduced in [[Internet Explorer 3]].<br />
<br />
== List of known builds==<br />
{{builds legend}}<br />
===16-bit version===<br />
====Platform Preview ====<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1005|4.0.1005}}<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1009|4.0.1009.3}}<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1321|4.0.1321}}<br />
<br />
====RTM ====<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1812|4.00.1812}}<br />
<br />
===32-bit version===<br />
====Nashville Plus Pack ====<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1056|4.70.1056}}<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1072|4.70.1072}}<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1074|4.70.1074}}<br />
====Alpha ====<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1101|4.70.1101}}<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1158|4.70.1158}}<!--Included in Windows 98 build 1351-1387, but it identifies as IE3 due to the lack of the Active Desktop shell--><br />
{{BLItem Leaked|Internet Explorer 4.0 build 1169|4.70.1169}}<br />
{{BLItem Leaked|Internet Explorer 4.0 build 0225|4.71.0225}}<br />
<br />
====Platform Preview 1 ====<br />
{{BLItem Leaked|Internet Explorer 4.0 build 0517.5|4.71.0517.5}}<!-- Included in Windows 98 build 1400 --><br />
{{BLItem Leaked|Internet Explorer 4.0 build 0531.0|4.71.0531.0}}<!-- The "Beta 1" reference in the About box has been replaced with "Platform Preview" and updated the copyright date from 1995-96 to 1995-97. Included in Windows 98 build 1410 and 1411 --><br />
{{BLItem Leaked|Internet Explorer 4.0 build 0531.1|4.71.0531.1}}<!-- Included in Windows 98 build 1415 --><br />
{{BLItem Leaked|Internet Explorer 4.0 build 0544|4.71.0544}} <!--This build's Active Desktop has the Show Desktop button as it appears in some builds of Windows 98 and NT 5.0.--><br />
====Platform Preview 2 ====<br />
{{BLItem Leaked|Internet Explorer 4.0 build 0603.1|4.71.0603.1}}<!-- Included in Windows 2000 build 1515 --> <br />
{{BLItem Leaked|Internet Explorer 4.0 build 0718.1|4.71.0718.1}}<!--This is the first build to show a splash screen. Included in Windows 98 build 1488--><br />
{{BLItem Leaked|Internet Explorer 4.0 build 0812.1|4.71.0812.1}}<!--Included in Windows 98 build 1500--><br />
{{BLItem Leaked|Internet Explorer 4.0 build 0828.0|4.71.0828.0}}<!--Removed the icons of Microsoft Chat and NetMeeting from the splash screen. Included in Windows 98 build 1511--><br />
{{BLItem Leaked|Internet Explorer 4.0 build 0904.1|4.71.0904.1}}<!--Included in Windows 98 build 1518--><br />
<br />
{{BLItem Leaked|Internet Explorer 4.0 build 0531.1|4.71.0911.1}}<!-- Included in Windows 2000 build 1575 --><br />
{{BLItem Leaked|Internet Explorer 4.0 build 0913.5|4.71.0913.5}}<!--Removed the splash screen. Included in Windows 98 builds 1525-32--><br />
{{BLItem Leaked|Internet Explorer 4.0 build 1003.0|4.71.1003.0}}<!--Included in Windows 98 build 1538--><br />
{{BLItem Leaked|Internet Explorer 4.0 build 1008.3|4.71.1008.3}}<!--Included in Windows 98 builds 1544 and 1546--><br />
{{BLItem Leaked|Internet Explorer 4 build 1008.4|4.71.1008.4}}<br />
====Plus Beta 2 ====<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1116|4.71.1116}}<!--Removed Platform Preview references and updated the About box to its final appearance. Included in Windows 98 build 1569--><br />
{{BLItem Leaked|Internet Explorer 4.0 build 1125.1|4.71.1125.1}}<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1127.1|4.71.1127.1}}<!--Included in Windows 98 build 1577--><br />
====IE 4.01 Beta ====<br />
{{BLItem Leaked|Internet Explorer 4.01 build 0103|4.72.0103}}<!--Included in Windows 98 build 1581.1--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 0118|4.72.0118}}<!--Replaced the [This product is licensed.] string in the About box with the Product ID. Included in Windows 98 build 1593--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 2002|4.72.2002}}<!--Included in Windows 98 build 1602--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 2027|4.72.2027}}<!--Included in Windows 98 build 1619--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 2103|4.72.2103}}<!--Included in Windows 98 build 1624--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 2106.2|4.72.2106.2}}<!--Added cipher strength to the About box. Included in Windows 98 build 1629--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 2106.6|4.72.2106.6}}<!--Included in Windows 98 build 1633--><br />
====IE 4.01 SP1 Beta ====<br />
{{BLItem Leaked|Internet Explorer 4.01 build 2908|4.72.2908}}<!--Included in Windows 98 build 1671--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 2915|4.72.2915}}<!--Included in Windows 98 build 1676--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 2922|4.72.2922}}<!--Included in Windows 98 build 1681--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 3007|4.72.3007}}<!--Included in Windows 98 builds 1687-91.3--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 3418|4.72.3026}}<!--Included in Windows 98 builds 1693 and 1702--><br />
====IE 4.01 SP2 Beta ====<br />
{{BLItem Leaked|Internet Explorer 4.01 build 3418|4.72.3418}} <!-- Included in Windows 98 build 2017 --><br />
{{BLItem Leaked|Internet Explorer 4.01 build 3610.0800|4.72.3610.0800}} <!-- Included in Windows 98 build 2088.5 --><br />
{{BLItem Leaked|Internet Explorer 4.01 build 3610.1000|4.72.3610.1000}} <!-- Included in Windows 98 build 2091 --><br />
<br />
====RTM ====<br />
{{BLItem Leaked|Internet Explorer 4.0 build 1712.6|4.71.1712.6 (4.0)}}<br />
{{BLItem Leaked|Internet Explorer 4.01 build 2106.8|4.72.2106.8 (4.01)}}<!--Included in Windows 98 builds 1650.3-66--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 3110.1|4.72.3110.1 (4.01 SP1(a))}}<!--Included in Windows 98 builds 1713-1998. Build 1998's IE4 refers to as SP1a instead of SP1 in earlier builds--><br />
{{BLItem Leaked|Internet Explorer 4.01 build 3682.1707|4.72.3682.1707 (4.01 SP2)}}<!--Released in March 1999 in tandem with IE 5.00--><br />
<br />
==Easter egg==<br />
There's a hidden easter egg in this version. To activate the egg, open the About dialog box, drag the IE logo to the globe while holding the {{key press|⇧ Shift}} key, then push the "Microsoft Internet Explorer 4.0" wordmark away. A "Unlock" button appears; click on it and drag the logo to the globe. The globe will zoom up and a list of Internet Explorer developers will show up.<br />
<br />
==Gallery==<br />
<gallery><br />
InternetExplorer4Setup.png|Setup<br />
InternetExplorer4FirstLoad.png|First boot<br />
InternetExplorer4ActiveDesktop.png|[[Windows NT 4.0 build 1381.335a]] with Active Desktop<br />
Windows-2000-5.0.1515.1-Desktop.png|[[Windows 2000 build 1515.1]] with Active Desktop<br />
Windows98-4.1.1559-Desktop.PNG|[[Windows 98 build 1559]] with Active Desktop<br />
1631.1 - Internet Explorer About.png|Internet Explorer 4 build 1008.4 on [[Windows 2000 build 1631.1]]<br />
InternetExplorer4FirstLoad2.png|Internet Explorer first load (loads a long-gone page from Microsoft)<br />
File:InternetExplorer4Demo.png|Demo<br />
</gallery><br />
[[Category:Internet Explorer]]<br />
[[Category:Internet Explorer 4.0 builds| ]]</div>2.204.223.225https://betawiki.net/index.php?title=Windows_10_build_9860&diff=212403Windows 10 build 98602022-05-15T23:18:59Z<p>2.204.223.225: /* Windows 9 reference */</p>
<hr />
<div>{{Infobox Windows build<br />
|build of = [[Windows 10 (original release)|Windows 10]]<br />
|image = Windows10-6.4.9860-Desktop.png<br />
|buildtag = 6.4.9860.0.fbl_release.141008-2044<br />
|arch = x86, x64<br />
|sku = Pro<br>Enterprise<br />
|compiled = 2014-10-08<br />
|timebomb = 2015-04-15<br />
|rivals = {{Rivals|TCB=http://www.thecollectionbook.info/builds/windows/build/1121|TCBGallery=http://www.thecollectionbook.info/gallery/?f=/windows/nt%20kernel/windows%2010/6.4.9860.0/english/technical%20preview%20update%20via%20pc%20settings}}<br />
|winver = Windows10-6.4.9860-About.png<br />
}}<br />
<br />
'''Windows 10 build 9860''' is the second officially released Technical Preview build of [[Windows 10 (original release)|Windows 10]]. Its buildtag was initially found through the ThresholdInternal build update mechanism on 10 October 2014. It was later released to those who joined the [[Windows Insider Program]] on 21 October 2014 and was downloadable via the Preview Builds build update mechanism in [[Windows 10 build 9841|build 9841]].<ref>[https://blogs.windows.com/windowsexperience/2014/10/21/were-rolling-out-our-first-new-build-to-the-windows-insider-program Windows Experience Blog]</ref><br />
<br />
== New features and changes ==<br />
* Action Center, a Windows Phone-like notification area, was returned compared to [[Windows 10 build 9841|build 9841]].<br />
* Support for the [https://en.wikipedia.org/wiki/Matroska Matroska] Multimedia Container and the [https://en.wikipedia.org/wiki/H.265 HEVC] codec has been introduced.<br />
* Metro apps can now run in screen resolutions lower than 1024x768.<br />
* Window animations have been updated.<br />
<br />
=== zPC settings ===<br />
In addition to the usual computer settings "[[Settings|PC settings]]" there is also a “zPC settings”. It also contains settings such as "OEM " and "Pendingor Deprecated” (literally translates to indefinite and obsolete), and judging by the various words inside, it contains a lot of banter.<br />
<br />
=== Hidden login screen ===<br />
A UWP login screen was added, to enable it, <code>Threshold</code> to 1 under <code>[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\TestHooks]</code> in the registry.<br />
<br />
=== XAML start menu ===<br />
This build has a XAML Start menu that is disabled by default. It is very buggy and works only by keyboard navigation.<br />
<br />
== Bugs ==<br />
=== Window thumbnail border color error ===<br />
If window auto-colorization is enabled, the window thumbnail borders on the taskbar do not change color even after the wallpaper changes. This issue can be remedied by manually changing the window color through the [[Control Panel]] or restarting Windows.<br />
<br />
== Windows 9 reference ==<br />
Starting with this build, a reference to the Windows 9 name can be found in <code>windows\System32\migwiz\replacementmanifests\CommandPrompt-Win8-Replacement.man</code>.<br />
<pre><br />
<!-- Gather blocks required for collecting data from Windows 8, Windows Blue, and some Windows 9 systems --><br />
<!-- Apply blocks required for applying to Windows 9 versions built BEFORE the correct CommandPrompt.man reaches winmain --><br />
<!-- The body of this should match CommandPrompt.man to fix Win9 systems before the changes reach winmain --><br />
<!-- 9845 is a guess of the build version when this will reach main. The correct CommandPrompt.man will be used after that build --><br />
</pre><br />
<br />
== Gallery ==<br />
<gallery><br />
Win8boot.png|Boot screen<br />
6.4.9821-Thumbnail-error.png|Incorrect window thumbnail border color<br />
</gallery><br />
<br />
== References ==<br />
<references /><br />
<br />
[[Category:Windows 10 builds]]</div>2.204.223.225https://betawiki.net/index.php?title=Windows_Vista_build_6002.16489&diff=212364Windows Vista build 6002.164892022-05-15T17:02:40Z<p>2.204.223.225: /* Bugs */</p>
<hr />
<div>{{Infobox Windows build<br />
|build of = [[Windows Vista]]<br />
|buildtag = 6.0.6002.16489.lh_sp2beta.080924-1740<br />
|image = WindowsVista-6002.16489-Desktop.png<br />
|arch = x86<br />
|compiled = 2008-09-24<br />
|timebomb = 2010-04-01<br />
|sku = Business N<br />
|winver = WindowsVista-6002.16489-About.png<br />
|rivals = {{Rivals|TCB=https://www.thecollectionbook.info/builds/windows/build/4754|TCBGallery=https://www.thecollectionbook.info/gallery/?f=/windows/nt%20kernel/windows%20vista/6.0.6002.16489/german/business%20n}}<br />
}}<br />
<br />
'''Windows Vista build 6002.16489''' is a Service Pack 2 beta build of [[Windows Vista]], which is only available in the x86 architecture and the "Business N" SKU in the German language.<br />
<br />
== Bugs and quirks ==<br />
=== Installation ===<br />
The installation media is not bootable due to missing bootcode. You must either upgrade from an earlier version of Windows or use a disc image editing tool to add boot information extracted from another build's media such as [[Windows Vista build 6001.18000|build 6001.18000]].<br />
===Media Features===<br />
Due to this build only being shared in the Business N SKU, media features such as [[Windows Media Player]] or [[Windows Movie Maker]] are missing. They can be readded with the Media Feature Pack for Windows Vista SP1/SP2.<br />
<br />
== Gallery ==<br />
<gallery><br />
WindowsVista-RTM-Boot.png|Boot screen<br />
vistabuild6002earliestoobede.png|OOBE<br />
vistabuild6002earliestlogonscreende.png|Login screen<br />
Startmenü6002dot16489.png|Start menu<br />
</gallery><br />
[[Category:Windows Vista Service Pack 2 builds]]<br />
[[Category:Windows Vista builds]]</div>2.204.223.225https://betawiki.net/index.php?title=Draft:Windows_build_FAQ&diff=212342Draft:Windows build FAQ2022-05-15T12:31:48Z<p>2.204.223.225: /* Earlier versions of Windows - partitin size limited to 2 GB */ fixed headline</p>
<hr />
<div>This is a help page to deal with the common questions that people ask when dealing with Windows builds. <br />
<br />
==General questions==<br />
<br />
===What's the "Build: " text at the bottom-right corner of the screen?===<br />
The Build: text is what is known as a buildstring. 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:<br />
<br />
a.a.xxxx.y.cccccccc.dddddd-dddd (a.a not displayed on desktop)<br />
<br />
where:<br />
{| class="wikitable"<br />
|+ Caption<br />
! Component !! Meaning<br />
|-<br />
| a.a || NT version number<br />
|-<br />
| xxxx || Build number<br />
|-<br />
| y || Build delta / revision<br />
|-<br />
| cccccccc || Build revision<br />
|-<br />
| dddddd-dddd || Date and time of start of compile in the format yymmmdd-mmss<br />
|}<br />
<br />
An example build string: 6.2.7950.winmain_win8m2.110223-1820<br />
Windows version 6.2 (Windows 8), build 7950, compiled in the <code>winmain_win8m2</code> branch, started on February 23, 2011, at 18:20<br />
The time is Pacific Standard TIme (PST), the timezone of Microsoft's Redmond campus, where the server farm that builds Windows is located.<br />
<br />
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.<br />
<br />
===How are builds found?===<br />
Since 2014, Microsoft flights builds - since 2016 typically from the <code>rs_prerelease</code> 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. <br />
<br />
===Can I have <build>?===<br />
No, with all certainty we don't have it. Find it yourself.<br />
<br />
===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?===<br />
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.<br />
<br />
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 [http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html|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.<br />
<br />
==== How is Windows built? ====<br />
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.<br />
<br />
==== How is Windows tested? ====<br />
Builds from non-main labs are typically tested by the teams responsible for them.<br />
<br />
For the main branch (currently <code>main</code>, historically <code>main</code> between 2000 and 2004, followed by <code>winmain</code>, <code>th2</code>, <code>rs1</code>, <code>rsmain</code> and <code>rsmaster</code>) 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 basic functionality and verification of components is done.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. At the same time, the build is tested on a very wide range 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. 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. Applications testing is then done to ensure compatibility with third-party application. Bugs, at least in 2004, were assigned to developers at a daily 9:30AM meeting known as "War Room", infamous for its fervent atmosphere with regular shouting matches.<br />
<br />
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. <br />
<br />
=== How is a Windows version developed? ===<br />
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.<br />
<br />
==== Before Windows 10 ====<br />
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.<br />
<br />
==== Windows 10 and later ====<br />
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). <br />
<br />
==== What version control system does Microsoft use? ====<br />
Before February 1986, Microsoft used [https://en.wikipedia.org/wiki/Source_Code_Control_System|Berkeley SCCS], the first ever version control system. After this, they moved to an internally developed clone of [https://en.wikipedia.org/wiki/Revision_Control_System|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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Do any Windows versions have source code leaked?===<br />
Yes. [[Windows NT 3.5 build 782.1|Windows NT 3.5 RC2]], [[Windows NT 4.0 build 1381.2|Windows NT 4.0 SP1]], and most of (enough to get a working build with some workarounds) [[Windows XP build 2600.1106|Windows XP SP1]] and [[Windows Server 2003 build 3790|Windows Server 2003]], as well as the original Xbox OS and ~2005 Live source.<br />
<br />
===What virtualisation software should I use?===<br />
If you are running classic Windows (Windows 1.x-3.x or 9x), or [[Windows NT 3.1 build 196.1|specific]] [[https://betawiki.net/wiki/Windows_2000_build_1671|NT builds]] then you should really use [https://86box.net|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.<br />
<br />
=== My ISO won't boot! ===<br />
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 <code>setup.exe</code> in the <code>WIN9X</code> directory and run it. For NT-based Windows, find <code>winnt.exe</code> in the <code>i386</code> directory 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. Or also, you can upgrade from an earlier build.<br />
<br />
=== How do I run Windows on ARM without an ARM machine? ===<br />
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.<br />
<br />
=== Timebomb information ===<br />
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.<br />
<br />
== Questions pertaining to specific versions ==<br />
<br />
=== Early DOS-based Windows - "incorrect DOS version" on DOS 5 or later, or DOSBox. ===<br />
These versions have a faulty version check that rejects any version that is not DOS 2.x or 3.x. You will have to use the SETVER utility on WIN100/200.BIN in order to report a version of 3.31 to this application, so it satisfies the check.<br />
<br />
=== Early DOS-based Windows - 32MB maximum partition size ===<br />
This is a FAT12 limitation and a DOS issue. You will need to upgrade toa version of DOS that supports FAT16, which is DOS 4.0 or later, as well as Compaq DOS 3.31 (developed with Microsoft's assistance), in order to install a larger drive.<br />
<br />
=== Windows 1.x - does pre-DR5 exist? ===<br />
The short answer is yes, there are at least two versions confirmed to exist. The long answer is good luck getting it. <br />
<br />
=== Windows 2.x - why are there no beta builds? ===<br />
Because none of them have been found yet.<br />
<br />
=== Windows 95 - General protection error on boot ===<br />
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 [http://lonecrusader.x10host.com/fix95cpu.html FIX95CPU] patch. <br />
<br />
=== Earlier versions of Windows - partition size limited to 2 GB ===<br />
This is a limitation of the FAT16 filesystem. To rectify this problem, you must convert to FAT32, NTFS, or some other filesystem, which requires Windows 95 OSR 2, Windows 98. Windows NT 4.0 (with a custom Winternals driver) and Windows 2000 also support it, but for NT-based OSes you really should be using NTFS anyway (the only circumstances you would need to use FAT with NT is for testing the Neptune Fastboot functionality). Windows 98 and SE include a GUI tool to convert, and Windows ME includes a DOS-based conversion tool. For Windows 2000 and later, the command <code>convert c: /fs:ntfs</code>, followed by a reboot, will do the trick.<br />
<br />
=== Earlier versions of Windows - partition size limited to 137.4 GB ===<br />
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.<br />
<br />
=== Windows 2000 - Reboot during last stage of setup===<br />
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.<br />
<br />
=== Windows 7 - I can't find some features! ===<br />
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 [https://github.com/gus33000/Bluepill here.]<br />
<br />
=== Windows 8 - there are missing features in the screenshots / where is Metro? ===<br />
If you are running a build before [[Windows 8 build 7814|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.</div>2.204.223.225https://betawiki.net/index.php?title=Draft:Windows_build_FAQ&diff=212341Draft:Windows build FAQ2022-05-15T12:30:29Z<p>2.204.223.225: /* Earlier versions of Windows - partitin size limited to 2 GB */</p>
<hr />
<div>This is a help page to deal with the common questions that people ask when dealing with Windows builds. <br />
<br />
==General questions==<br />
<br />
===What's the "Build: " text at the bottom-right corner of the screen?===<br />
The Build: text is what is known as a buildstring. 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:<br />
<br />
a.a.xxxx.y.cccccccc.dddddd-dddd (a.a not displayed on desktop)<br />
<br />
where:<br />
{| class="wikitable"<br />
|+ Caption<br />
! Component !! Meaning<br />
|-<br />
| a.a || NT version number<br />
|-<br />
| xxxx || Build number<br />
|-<br />
| y || Build delta / revision<br />
|-<br />
| cccccccc || Build revision<br />
|-<br />
| dddddd-dddd || Date and time of start of compile in the format yymmmdd-mmss<br />
|}<br />
<br />
An example build string: 6.2.7950.winmain_win8m2.110223-1820<br />
Windows version 6.2 (Windows 8), build 7950, compiled in the <code>winmain_win8m2</code> branch, started on February 23, 2011, at 18:20<br />
The time is Pacific Standard TIme (PST), the timezone of Microsoft's Redmond campus, where the server farm that builds Windows is located.<br />
<br />
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.<br />
<br />
===How are builds found?===<br />
Since 2014, Microsoft flights builds - since 2016 typically from the <code>rs_prerelease</code> 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. <br />
<br />
===Can I have <build>?===<br />
No, with all certainty we don't have it. Find it yourself.<br />
<br />
===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?===<br />
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.<br />
<br />
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 [http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html|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.<br />
<br />
==== How is Windows built? ====<br />
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.<br />
<br />
==== How is Windows tested? ====<br />
Builds from non-main labs are typically tested by the teams responsible for them.<br />
<br />
For the main branch (currently <code>main</code>, historically <code>main</code> between 2000 and 2004, followed by <code>winmain</code>, <code>th2</code>, <code>rs1</code>, <code>rsmain</code> and <code>rsmaster</code>) 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 basic functionality and verification of components is done.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. At the same time, the build is tested on a very wide range 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. 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. Applications testing is then done to ensure compatibility with third-party application. Bugs, at least in 2004, were assigned to developers at a daily 9:30AM meeting known as "War Room", infamous for its fervent atmosphere with regular shouting matches.<br />
<br />
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. <br />
<br />
=== How is a Windows version developed? ===<br />
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.<br />
<br />
==== Before Windows 10 ====<br />
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.<br />
<br />
==== Windows 10 and later ====<br />
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). <br />
<br />
==== What version control system does Microsoft use? ====<br />
Before February 1986, Microsoft used [https://en.wikipedia.org/wiki/Source_Code_Control_System|Berkeley SCCS], the first ever version control system. After this, they moved to an internally developed clone of [https://en.wikipedia.org/wiki/Revision_Control_System|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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Do any Windows versions have source code leaked?===<br />
Yes. [[Windows NT 3.5 build 782.1|Windows NT 3.5 RC2]], [[Windows NT 4.0 build 1381.2|Windows NT 4.0 SP1]], and most of (enough to get a working build with some workarounds) [[Windows XP build 2600.1106|Windows XP SP1]] and [[Windows Server 2003 build 3790|Windows Server 2003]], as well as the original Xbox OS and ~2005 Live source.<br />
<br />
===What virtualisation software should I use?===<br />
If you are running classic Windows (Windows 1.x-3.x or 9x), or [[Windows NT 3.1 build 196.1|specific]] [[https://betawiki.net/wiki/Windows_2000_build_1671|NT builds]] then you should really use [https://86box.net|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.<br />
<br />
=== My ISO won't boot! ===<br />
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 <code>setup.exe</code> in the <code>WIN9X</code> directory and run it. For NT-based Windows, find <code>winnt.exe</code> in the <code>i386</code> directory 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. Or also, you can upgrade from an earlier build.<br />
<br />
=== How do I run Windows on ARM without an ARM machine? ===<br />
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.<br />
<br />
=== Timebomb information ===<br />
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.<br />
<br />
== Questions pertaining to specific versions ==<br />
<br />
=== Early DOS-based Windows - "incorrect DOS version" on DOS 5 or later, or DOSBox. ===<br />
These versions have a faulty version check that rejects any version that is not DOS 2.x or 3.x. You will have to use the SETVER utility on WIN100/200.BIN in order to report a version of 3.31 to this application, so it satisfies the check.<br />
<br />
=== Early DOS-based Windows - 32MB maximum partition size ===<br />
This is a FAT12 limitation and a DOS issue. You will need to upgrade toa version of DOS that supports FAT16, which is DOS 4.0 or later, as well as Compaq DOS 3.31 (developed with Microsoft's assistance), in order to install a larger drive.<br />
<br />
=== Windows 1.x - does pre-DR5 exist? ===<br />
The short answer is yes, there are at least two versions confirmed to exist. The long answer is good luck getting it. <br />
<br />
=== Windows 2.x - why are there no beta builds? ===<br />
Because none of them have been found yet.<br />
<br />
=== Windows 95 - General protection error on boot ===<br />
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 [http://lonecrusader.x10host.com/fix95cpu.html FIX95CPU] patch. <br />
<br />
=== Earlier versions of Windows - partitin size limited to 2 GB ===<br />
This is a limitation of the FAT16 filesystem. To rectify this problem, you must convert to FAT32, NTFS, or some other filesystem, which requires Windows 95 OSR 2, Windows 98. Windows NT 4.0 (with a custom Winternals driver) and Windows 2000 also support it, but for NT-based OSes you really should be using NTFS anyway (the only circumstances you would need to use FAT with NT is for testing the Neptune Fastboot functionality). Windows 98 and SE include a GUI tool to convert, and Windows ME includes a DOS-based conversion tool. For Windows 2000 and later, the command <code>convert c: /fs:ntfs</code>, followed by a reboot, will do the trick.<br />
<br />
=== Earlier versions of Windows - partition size limited to 137.4 GB ===<br />
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.<br />
<br />
=== Windows 2000 - Reboot during last stage of setup===<br />
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.<br />
<br />
=== Windows 7 - I can't find some features! ===<br />
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 [https://github.com/gus33000/Bluepill here.]<br />
<br />
=== Windows 8 - there are missing features in the screenshots / where is Metro? ===<br />
If you are running a build before [[Windows 8 build 7814|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.</div>2.204.223.225https://betawiki.net/index.php?title=Draft:Windows_build_FAQ&diff=212339Draft:Windows build FAQ2022-05-15T12:29:10Z<p>2.204.223.225: /* My ISO won't boot! */</p>
<hr />
<div>This is a help page to deal with the common questions that people ask when dealing with Windows builds. <br />
<br />
==General questions==<br />
<br />
===What's the "Build: " text at the bottom-right corner of the screen?===<br />
The Build: text is what is known as a buildstring. 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:<br />
<br />
a.a.xxxx.y.cccccccc.dddddd-dddd (a.a not displayed on desktop)<br />
<br />
where:<br />
{| class="wikitable"<br />
|+ Caption<br />
! Component !! Meaning<br />
|-<br />
| a.a || NT version number<br />
|-<br />
| xxxx || Build number<br />
|-<br />
| y || Build delta / revision<br />
|-<br />
| cccccccc || Build revision<br />
|-<br />
| dddddd-dddd || Date and time of start of compile in the format yymmmdd-mmss<br />
|}<br />
<br />
An example build string: 6.2.7950.winmain_win8m2.110223-1820<br />
Windows version 6.2 (Windows 8), build 7950, compiled in the <code>winmain_win8m2</code> branch, started on February 23, 2011, at 18:20<br />
The time is Pacific Standard TIme (PST), the timezone of Microsoft's Redmond campus, where the server farm that builds Windows is located.<br />
<br />
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.<br />
<br />
===How are builds found?===<br />
Since 2014, Microsoft flights builds - since 2016 typically from the <code>rs_prerelease</code> 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. <br />
<br />
===Can I have <build>?===<br />
No, with all certainty we don't have it. Find it yourself.<br />
<br />
===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?===<br />
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.<br />
<br />
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 [http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html|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.<br />
<br />
==== How is Windows built? ====<br />
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.<br />
<br />
==== How is Windows tested? ====<br />
Builds from non-main labs are typically tested by the teams responsible for them.<br />
<br />
For the main branch (currently <code>main</code>, historically <code>main</code> between 2000 and 2004, followed by <code>winmain</code>, <code>th2</code>, <code>rs1</code>, <code>rsmain</code> and <code>rsmaster</code>) 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 basic functionality and verification of components is done.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. At the same time, the build is tested on a very wide range 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. 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. Applications testing is then done to ensure compatibility with third-party application. Bugs, at least in 2004, were assigned to developers at a daily 9:30AM meeting known as "War Room", infamous for its fervent atmosphere with regular shouting matches.<br />
<br />
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. <br />
<br />
=== How is a Windows version developed? ===<br />
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.<br />
<br />
==== Before Windows 10 ====<br />
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.<br />
<br />
==== Windows 10 and later ====<br />
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). <br />
<br />
==== What version control system does Microsoft use? ====<br />
Before February 1986, Microsoft used [https://en.wikipedia.org/wiki/Source_Code_Control_System|Berkeley SCCS], the first ever version control system. After this, they moved to an internally developed clone of [https://en.wikipedia.org/wiki/Revision_Control_System|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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Do any Windows versions have source code leaked?===<br />
Yes. [[Windows NT 3.5 build 782.1|Windows NT 3.5 RC2]], [[Windows NT 4.0 build 1381.2|Windows NT 4.0 SP1]], and most of (enough to get a working build with some workarounds) [[Windows XP build 2600.1106|Windows XP SP1]] and [[Windows Server 2003 build 3790|Windows Server 2003]], as well as the original Xbox OS and ~2005 Live source.<br />
<br />
===What virtualisation software should I use?===<br />
If you are running classic Windows (Windows 1.x-3.x or 9x), or [[Windows NT 3.1 build 196.1|specific]] [[https://betawiki.net/wiki/Windows_2000_build_1671|NT builds]] then you should really use [https://86box.net|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.<br />
<br />
=== My ISO won't boot! ===<br />
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 <code>setup.exe</code> in the <code>WIN9X</code> directory and run it. For NT-based Windows, find <code>winnt.exe</code> in the <code>i386</code> directory 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. Or also, you can upgrade from an earlier build.<br />
<br />
=== How do I run Windows on ARM without an ARM machine? ===<br />
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.<br />
<br />
=== Timebomb information ===<br />
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.<br />
<br />
== Questions pertaining to specific versions ==<br />
<br />
=== Early DOS-based Windows - "incorrect DOS version" on DOS 5 or later, or DOSBox. ===<br />
These versions have a faulty version check that rejects any version that is not DOS 2.x or 3.x. You will have to use the SETVER utility on WIN100/200.BIN in order to report a version of 3.31 to this application, so it satisfies the check.<br />
<br />
=== Early DOS-based Windows - 32MB maximum partition size ===<br />
This is a FAT12 limitation and a DOS issue. You will need to upgrade toa version of DOS that supports FAT16, which is DOS 4.0 or later, as well as Compaq DOS 3.31 (developed with Microsoft's assistance), in order to install a larger drive.<br />
<br />
=== Windows 1.x - does pre-DR5 exist? ===<br />
The short answer is yes, there are at least two versions confirmed to exist. The long answer is good luck getting it. <br />
<br />
=== Windows 2.x - why are there no beta builds? ===<br />
Because none of them have been found yet.<br />
<br />
=== Windows 95 - General protection error on boot ===<br />
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 [http://lonecrusader.x10host.com/fix95cpu.html FIX95CPU] patch. <br />
<br />
=== Earlier versions of Windows - partitin size limited to 2 GB ===<br />
This is a limitation of the FAT16 filesystem. To rectify this problem, you must convert to FAT32, NTFS, or some other filesystem, which requires Windows 95 OSR 2, Windows 98. Windows NT 4.0 (with a custom Winternals driver) and Windows 2000 also support it, but for NT-based OSes you really should be using NTFS anyway (the only circumstances you would need to use FAT with NT is for testing the Neptune Fastboot functionality). Windows 98 and SE include a GUI tool to convert, and Windows ME includes a DOS-based conversion tool. For Windows 2000, the command <code>convert c: /fs:ntfs</code>, followed by a reboot, will do the trick. <br />
<br />
=== Earlier versions of Windows - partition size limited to 137.4 GB ===<br />
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.<br />
<br />
=== Windows 2000 - Reboot during last stage of setup===<br />
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.<br />
<br />
=== Windows 7 - I can't find some features! ===<br />
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 [https://github.com/gus33000/Bluepill here.]<br />
<br />
=== Windows 8 - there are missing features in the screenshots / where is Metro? ===<br />
If you are running a build before [[Windows 8 build 7814|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.</div>2.204.223.225https://betawiki.net/index.php?title=Draft:Windows_build_FAQ&diff=212335Draft:Windows build FAQ2022-05-15T12:26:34Z<p>2.204.223.225: </p>
<hr />
<div>This is a help page to deal with the common questions that people ask when dealing with Windows builds. <br />
<br />
==General questions==<br />
<br />
===What's the "Build: " text at the bottom-right corner of the screen?===<br />
The Build: text is what is known as a buildstring. 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:<br />
<br />
a.a.xxxx.y.cccccccc.dddddd-dddd (a.a not displayed on desktop)<br />
<br />
where:<br />
{| class="wikitable"<br />
|+ Caption<br />
! Component !! Meaning<br />
|-<br />
| a.a || NT version number<br />
|-<br />
| xxxx || Build number<br />
|-<br />
| y || Build delta / revision<br />
|-<br />
| cccccccc || Build revision<br />
|-<br />
| dddddd-dddd || Date and time of start of compile in the format yymmmdd-mmss<br />
|}<br />
<br />
An example build string: 6.2.7950.winmain_win8m2.110223-1820<br />
Windows version 6.2 (Windows 8), build 7950, compiled in the <code>winmain_win8m2</code> branch, started on February 23, 2011, at 18:20<br />
The time is Pacific Standard TIme (PST), the timezone of Microsoft's Redmond campus, where the server farm that builds Windows is located.<br />
<br />
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.<br />
<br />
===How are builds found?===<br />
Since 2014, Microsoft flights builds - since 2016 typically from the <code>rs_prerelease</code> 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. <br />
<br />
===Can I have <build>?===<br />
No, with all certainty we don't have it. Find it yourself.<br />
<br />
===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?===<br />
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.<br />
<br />
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 [http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html|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.<br />
<br />
==== How is Windows built? ====<br />
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.<br />
<br />
==== How is Windows tested? ====<br />
Builds from non-main labs are typically tested by the teams responsible for them.<br />
<br />
For the main branch (currently <code>main</code>, historically <code>main</code> between 2000 and 2004, followed by <code>winmain</code>, <code>th2</code>, <code>rs1</code>, <code>rsmain</code> and <code>rsmaster</code>) 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 basic functionality and verification of components is done.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. At the same time, the build is tested on a very wide range 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. 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. Applications testing is then done to ensure compatibility with third-party application. Bugs, at least in 2004, were assigned to developers at a daily 9:30AM meeting known as "War Room", infamous for its fervent atmosphere with regular shouting matches.<br />
<br />
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. <br />
<br />
=== How is a Windows version developed? ===<br />
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.<br />
<br />
==== Before Windows 10 ====<br />
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.<br />
<br />
==== Windows 10 and later ====<br />
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). <br />
<br />
==== What version control system does Microsoft use? ====<br />
Before February 1986, Microsoft used [https://en.wikipedia.org/wiki/Source_Code_Control_System|Berkeley SCCS], the first ever version control system. After this, they moved to an internally developed clone of [https://en.wikipedia.org/wiki/Revision_Control_System|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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Do any Windows versions have source code leaked?===<br />
Yes. [[Windows NT 3.5 build 782.1|Windows NT 3.5 RC2]], [[Windows NT 4.0 build 1381.2|Windows NT 4.0 SP1]], and most of (enough to get a working build with some workarounds) [[Windows XP build 2600.1180|Windows XP SP1]] and [[Windows Server 2003 build 3790|Windows Server 2003]], as well as the original Xbox OS and ~2005 Live source.<br />
<br />
===What virtualisation software should I use?===<br />
If you are running classic Windows (Windows 1.x-3.x or 9x), or [[Windows NT 3.1 build 196.1|specific]] [[https://betawiki.net/wiki/Windows_2000_build_1671|NT builds]] then you should really use [https://86box.net|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.<br />
<br />
=== My ISO won't boot! ===<br />
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 <code>setup.exe</code> and run it. For NT-based Windows, find <code>winnt.exe</code> 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. Or also, you can upgrade from an earlier build.<br />
<br />
=== How do I run Windows on ARM without an ARM machine? ===<br />
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.<br />
<br />
=== Timebomb information ===<br />
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.<br />
<br />
== Questions pertaining to specific versions ==<br />
<br />
=== Early DOS-based Windows - "incorrect DOS version" on DOS 5 or later, or DOSBox. ===<br />
These versions have a faulty version check that rejects any version that is not DOS 2.x or 3.x. You will have to use the SETVER utility on WIN100/200.BIN in order to report a version of 3.31 to this application, so it satisfies the check.<br />
<br />
=== Early DOS-based Windows - 32MB maximum partition size ===<br />
This is a FAT12 limitation and a DOS issue. You will need to upgrade toa version of DOS that supports FAT16, which is DOS 4.0 or later, as well as Compaq DOS 3.31 (developed with Microsoft's assistance), in order to install a larger drive.<br />
<br />
=== Windows 1.x - does pre-DR5 exist? ===<br />
The short answer is yes, there are at least two versions confirmed to exist. The long answer is good luck getting it. <br />
<br />
=== Windows 2.x - why are there no beta builds? ===<br />
Because none of them have been found yet.<br />
<br />
=== Windows 95 - General protection error on boot ===<br />
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 [http://lonecrusader.x10host.com/fix95cpu.html FIX95CPU] patch. <br />
<br />
=== Earlier versions of Windows - hard drive size limited to 137.4 GB ===<br />
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.<br />
<br />
=== Windows 2000 - Reboot during last stage of setup===<br />
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.<br />
<br />
=== Windows 7 - I can't find some features! ===<br />
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 [https://github.com/gus33000/Bluepill here.]<br />
<br />
=== Windows 8 - there are missing features in the screenshots / where is Metro? ===<br />
If you are running a build before [[Windows 8 build 7814|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.</div>2.204.223.225https://betawiki.net/index.php?title=BetaWiki:Administrators%27_noticeboard&diff=212334BetaWiki:Administrators' noticeboard2022-05-15T12:24:34Z<p>2.204.223.225: /* The abuse filter blocks me from editing the Debian page! */ new section</p>
<hr />
<div>__NEWSECTIONLINK__<br />
{{fmbox|type=system|image=none|text=<center><br />
<span style="font-size: 150%;">Welcome to BetaWiki administrators' noticeboard!</span><br />
<br />
Use this page to request operations that can't be done without administrator (sysop) privileges. This includes user account renames, content import requests, or requests for auto-moderated status.<br />
<br />
Requests that can be satisfied by non-administrator users should be raised at the [[BetaWiki:community portal|community portal]]. [[Main Page]] issues should be raised at its [[Talk:Main Page|talk page]].<br />
<br />
To add a discussion, please add a new heading under this line.<br />
</center><br />
}}<br />
{{archives}}<br />
{{TOC|clear=left|limit=2}}<br />
<br />
== Move these pages. ==<br />
=== First move ===<br />
There are 2 windows 2000 builds it was not moved. This is the list of not moved Windows 2000 builds:<br />
*{{BLItem Confirmed|Windows 2000 build 1781.1|1781.1}}<br />
*{{BLItem Confirmed|Windows 2000 build 1794.1|1794.1}}<br />
[[Special:Contributions/2001:f90:40c0:a072:5189:e019:ae56:b207|2001:f90:40c0:a072:5189:e019:ae56:b207]] 18:53, 12 May 2022 (UTC+08:00)<br />
:Could you also move [[Windows Live Messenger build 14.0.3921]] to [[Windows Live Messenger 2009 build 3921]]? The page already exists, but it is a redirect. - [[Special:Contributions/212.23.130.206|212.23.130.206]] <sup>([[User talk:212.23.130.206|talk]])</sup> 13:34, 12 May 2022 (UTC)<br />
::{{done}} --[[User:Nara Insider|Nara Insider]] ([[User talk:Nara Insider|talk]]) 11:48, 13 May 2022 (UTC)<br />
=== Second move ===<br />
Please, move this page.<br />
*{{BLItem Unconfirmed|Windows NT 4.0 build 1124.1|1124.1}}'''(ATTEMPT: Move this page to [[Windows NT 4.0 build 1124]]. In this attempt you must move before 08:53, 15 May 2022 (UTC).)''' [[Special:Contributions/2001:f90:40c0:a072:2193:ed23:ccfd:7a64|2001:f90:40c0:a072:2193:ed23:ccfd:7a64]] 16:53, 14 May 2022 (UTC+08:00)<br />
:And what would happen if we didn't? Seems dumb to set a deadline for a simple move [[User:Xeno|Xeno]] ([[User talk:Xeno|talk]]) 11:57, 14 May 2022 (UTC)<br />
::If didn't moved before that time, I will give last 5 days time for you. [[Special:Contributions/2001:f90:40c0:a072:f805:cd7:28b:ff74|2001:f90:40c0:a072:2193:ed23:ccfd:7a64]] 12:00, 15 May 2022 (UTC+08:00)<br />
<br />
== Unblock request ==<br />
<br />
Can someone unbock Ilyes before 5 April else his IP adress will violate the guidelines - 197.202.123.182<br />
:That is a great way to achieve the exact opposite of what you're asking for. --{{User:Ryuzaki/Signature}} 17:39, 19 March 2022 (UTC)<br />
::You have two options: 1. Unblock me before 5th April or 2. Leave this site forever - 197.202.123.182<br />
:::LLyes wanna be on a team?? (Im windows 2005 :D :) :I :p) [[User:LLyEs 2005|LLyEs 2005]] ([[User talk:LLyEs 2005|talk]]) 20:27, 19 March 2022 (UTC) (beeschurger1<br />
<br />
== Please create more Windows game articles ==<br />
<br />
*[[Card Games]] (etc. for Solitaire, Spider, Hearts, Spades, FreeCell)<br />
*[[Microsoft Mahjong]]<br />
*[[Chess Titans]]<br />
*[[Purble Place]]<br />
*[[Hover!]]<br />
*[[Microsoft Minesweeper]]<br />
[[Special:Contributions/78.160.125.93|78.160.125.93]] 00:56, 23 March 2022 (UTC)<br />
:I will create those when I am automoderated. [[User:XPBeta|XPBeta]] ([[User talk:XPBeta|talk]]) 01:53, 23 March 2022 (UTC)<br />
:That's not a request for an administrator action. => [[BetaWiki:Community portal|Community portal]] --{{User:Ryuzaki/Signature}} 18:11, 27 March 2022 (UTC)<br />
<br />
== Please make me automoderated ==<br />
<br />
Please make me automoderated. [[User:XPBeta|XPBeta]] ([[User talk:XPBeta|talk]]) 01:52, 23 March 2022 (UTC)<br />
:First, automoderated hasn't been relevant in years. Second, you basically made 10 spammy edits to the Sandbox to satisfy the autoconfirmed criterion and then immediately asked for automoderated, so I don't know what you expect me to do. You have zero editing history behind you, so that's a big nope. --{{User:Ryuzaki/Signature}} 03:16, 23 March 2022 (UTC)<br />
<br />
== Please unblock XPBeta ==<br />
<br />
He did nothing wrong, but it is a false positive. Please unblock him. I am using a VPN to post this, cause I don't wait my account to be unblocked. F**k you the abuse filter. [[Special:Contributions/163.172.181.151|163.172.181.151]] 02:06, 23 March 2022 (UTC)<br />
<br />
== Delete this account ==<br />
<br />
Hi, can administrators delete the user ''Ilyes'' as I no longer need it since I will not do edit conflicts with an IP/MAC adress. Thanks - 105.105.71.212<br />
:No, we can't delete accounts. --{{User:Ryuzaki/Signature}} 18:11, 27 March 2022 (UTC)<br />
<br />
== SVGs should save as PNGs ==<br />
<br />
SVGs save as SVGs. Shouldn't they be PNGs? If there's any way to fix this, please do.<br />
: Why don't you save them as .PNG then? [[User:ToMi|ToMi]] ([[User talk:ToMi|talk]]) 14:21, 10 April 2022 (UTC)<br />
:: To clarify, all the other MediaWiki-based wikis have SVGs in some sort of PNG-based format. It doesn't seem to happen here.<br />
::: Yes, that is very much intentional. SVG is supported by any reasonably modern browser, so there is no reason to convert it to PNG in 2022. --{{User:Ryuzaki/Signature}} 14:56, 17 April 2022 (UTC)<br />
:No? SVG files can't be saved as PNGs. If you're talking about a way to export it as a PNG, then just save the thumbnails that are generated from the SVG. There are also online tools that can turn an SVG into a PNG. [[User:Jurta|Jurta]] ([[User talk:Jurta|talk]] • [[Special:Contributions/Jurta|contribs]]) 14:06, 17 April 2022 (UTC)<br />
<br />
== Page restore ==<br />
<br />
Could be [[:Category:Windows 10 Fall Creators Update builds]] restored? Thanks. [[User:ToMi|ToMi]] ([[User talk:ToMi|talk]]) 14:00, 18 April 2022 (UTC)<br />
:It was undeleted. [[Special:Contributions/105.111.109.145|105.111.109.145]] 15:54, 7 May 2022 (UTC)<br />
:We say restored. [[Special:Contributions/2001:f90:40c0:a072:d963:d209:5f65:74d9|2001:f90:40c0:a072:d963:d209:5f65:74d9]] 19:14, 10 May 2022 (UTC+08:00)<br />
<br />
== Impolite editor:Starfrost ==<br />
<br />
The user unreasonably deleted my user page, if he is one of the administrators, should give a reasonable reason to delete this page. Otherwise, please give a reasonable ban or punishment according to the behavior of this user—[[User:MakiAdmin|MakiAdmin]] ([[User talk:MakiAdmin|talk]]) 06:35, 25 April 2022 (UTC)<br />
:Hey, sorry about that. We recently performed a clean-up within the Main: and User: namespaces and removed any pages that didn't appear to provide any useful content, fell under the WNR rule, were created by blocked users or were entirely unneeded redirects. I've restored all revisions of your user page and reverted it to the last revision made before yours was accidentally removed from the User: namespace. Again, I sincerely apologize for any inconvenience the staff team caused. Have a great day! - [[User:Pivotman319|pivotman319]] ([[User_talk:Pivotman319|📫]]) 08:07, 25 April 2022 (UTC)<br />
<br />
== Change my username please (again) ==<br />
<br />
Hey, can any admin please change my username from "Bubblebeam" to "Uncle Captain"? Because I am starting to not like my current one anymore. [[User:Bubblebeam|Uncle Captain]] ([[User talk:Bubblebeam|talk]]) 01:11, 26 April 2022 (UTC)<br />
:According to Ryu (Me ) on the Discord server. You'll be able to change your name in Mid-september. The rules changed to one rename per year. [[User:Xeno|Xeno]] ([[User talk:Xeno|talk]]) 01:43, 26 April 2022 (UTC)<br />
::That's ok, I can wait until 3 September 2022. :) [[User:Bubblebeam|Uncle Captain]] ([[User talk:Bubblebeam|talk]]) 01:59, 26 April 2022 (UTC)<br />
:::@Xeno But still, the guidelines still say 6 months. [[User:Bubblebeam|Uncle Captain]] ([[User talk:Bubblebeam|talk]]) 02:00, 26 April 2022 (UTC)<br />
::::It actually says "If your account is at least 6 months old and you haven't already done so ''less than a year ago''". So yeah, sorry. --{{User:Ryuzaki/Signature}} 02:04, 26 April 2022 (UTC)<br />
<br />
== I want to change my username ==<br />
<br />
Sorry I entered the wrong username when I registered, so I need to change my username to "toorich" if nobody used this username. --[[User:北京|北京]] ([[User talk:北京|talk]]) 15:26, 2 May 2022 (UTC)<br />
:You have been renamed. [[Special:Contributions/105.111.109.145|105.111.109.145]] 15:53, 7 May 2022 (UTC)<br />
:Your time was 15:53 7 may 2022 UTC. And these 5 days already renamed. (...)<br />
<br />
== Restore a page ==<br />
<br />
Could [[Windows 10 build 10240.16425]] be restored?<br />
<br />
I have an issue with the deletion of this article. Let me explain.<br />
<br />
According to gus33000 (https://discord.com/channels/305415513503432705/305415513503432705/792657232511893514), this build is a full build rather than a cumulative update.<br />
<br />
Besides, I checked the update (windows10.0-kb3081436-x64_4f2d2481f0f3364635a185a20605aa8190c6c951.msu) mentioned in the QD reason. As said in [[Talk:Windows_10_build_10240.16425|the talk page]], after applying the update the version string is 10.0.10240.'''16430''', and only very few files have version number 10240.16425.<br />
<br />
Based on the above information, I don't think this deletion is completely reasonable and request to restore this page.<br />
--[[User:BlueRain|BlueRain]] ([[User talk:BlueRain|talk]]) 06:37, 9 May 2022 (UTC)<br />
<br />
Restored.<br />
== Block a user call [[User:Sarma Abhirrasama|Sarma Abhirrasama]]. ==<br />
This user was say [[Windows Vista build 5734]] was leaked. Before, that build was unconfirmed, this can be blocked. (?) [[Special:Contributions/2001:f90:40c0:a072:5189:e019:ae56:b207|2001:f90:40c0:a072:5189:e019:ae56:b207]] 17:26, 11 May 2022 (UTC+08:00)<br />
<br />
== Block Jack Whiskers ==<br />
<br />
He is writing on the Win98 page sth about Rugrats, Toys R' Us <sup>(rip)</sup>, Looney Tunes and Paramount. Before he continues with more vandalism, you should rather block him. - [[Special:Contributions/2.207.30.181|<bdi>2.207.30.181</bdi>]] <sup>([[User talk:2.207.30.181|talk]])</sup> 23:36, 14 May 2022<br />
<br />
== Block this user (47.40.250.35) ==<br />
He is writing on the [[iPhone OS 1]] page for a fake 1C26 build. In iOS NEVER RELEASED 1C26. I doesn't know is he blocked. Please block him. [[Special:Contributions/2001:F90:40C0:A072:F805:CD7:28B:FF74|2001:F90:40C0:A072:F805:CD7:28B:FF74]] 09:44, 15 May 2022 (UTC+08:00)<br />
<br />
== The abuse filter blocks me from editing the Debian page! ==<br />
<br />
I only wanted to add a new row for the version history wikitable, where the long-term support dates shall be listed, but the abuse filter blocks me from doing that due to "adding repetitive content". - [[Special:Contributions/2.204.223.225|2.204.223.225]] <sup>([[User talk:2.204.223.225|talk]])</sup> 12:24, 15 May 2022</div>2.204.223.225https://betawiki.net/index.php?title=Debian&diff=212300Debian2022-05-15T09:57:22Z<p>2.204.223.225: </p>
<hr />
<div>{{Infobox Linux distribution<br />
|name = Debian<br />
|image = Debian_11_gnome.png<br />
|image-caption = Debian 11 desktop<br />
|releasetype = Fixed<br />
|releasedate = 17 June 1996<br />
|latestbuild = [[Debian 11.0]]<br />
|arch = i386, amd64, arm64, armel, armhf, mips, mips64el, mipsel, ppc64el, s390x<br />
|ui = [[GNOME]], [[Xfce]], [[KDE Plasma]], [[Cinnamon]], [[MATE]], [[LXDE]], [[LXQt]]<br />
|package = apt<br />
|status = Active<br />
|terminal = bash<br />
}}<br />
'''Debian''' is a Linux distribution that forms the base of the [[Ubuntu]] operating system in infrastructure.<br />
<br />
== Timeline ==<br />
All versions of Debian are named after characters from the film franchise "Toy Story".<br />
<br />
{| class="wikitable" style="width: 100%"<br />
|-<br />
|-<br />
! Name<br />
! Codename<br />
! Release date<br />
! Support end date<br />
|-<br />
|{{version|unsupported|[[Debian 1.1]]}}<br />
|Buzz<br />
|17 June 1996<br />
|<br />
|-<br />
|{{version|unsupported|[[Debian 1.2]]}}<br />
|Rex<br />
|12 December 1996<br />
|<br />
|-<br />
|{{version|unsupported|[[Debian 1.3]]}}<br />
|Bo<br />
|5 June 1997<br />
|14 May 1998<br />
|-<br />
|{{version|unsupported|[[Debian 2.0]]}}<br />
|Hamm<br />
|24 July 1998<br />
|15 February 1999<br />
|-<br />
|{{version|unsupported|[[Debian 2.1]]}}<br />
|Slink<br />
|9 March 1999<br />
|30 October 2000<br />
|-<br />
|{{version|unsupported|[[Debian 2.2]]}}<br />
|Potato<br />
|15 August 2000<br />
|30 June 2003<br />
|-<br />
|{{version|unsupported|[[Debian 3.0]]}}<br />
|Woody<br />
|19 July 2002<br />
|30 June 2006<br />
|-<br />
|{{version|unsupported|[[Debian 3.1]]}}<br />
|Sarge<br />
|6 June 2005<br />
|31 March 2008<br />
|-<br />
|{{version|unsupported|[[Debian 4.0]]}}<br />
|Etch<br />
|8 April 2007<br />
|15 February 2010<br />
|-<br />
|{{version|unsupported|[[Debian 5.0]]}}<br />
|Lenny<br />
|14 February 2009<br />
|6 February 2012<br />
|-<br />
|{{version|unsupported|[[Debian 6.0]]}}<br />
|Squeeze<br />
|6 February 2011<br />
|31 May 2014; Long term support for IA-32 and x86-64 ended on 29 February 2016<br />
|-<br />
|{{version|unsupported|[[Debian 7.0]]}}<br />
|Wheezy<br />
|4 May 2013<br />
|26 April 2016; Long term support for IA-32 and x86-64 ended on 31 May 2018<br />
|-<br />
|{{version|unsupported|[[Debian 8.0]]}}<br />
|Jessie<br />
|25 April 2015<br />
|17 June 2018; Long term support for IA-32 and x86-64 ended on 30 June 2020<br />
|-<br />
|{{version|supported|[[Debian 9.0]]}}<br />
|Stretch<br />
|17 June 2017<br />
|6 July 2020; Long term support for IA-32 and x86-64 will end on 30 June 2022<br />
|-<br />
|{{version|supported|[[Debian 10.0]]}}<br />
|Buster<br />
|6 July 2019<br />
|August 2022; Long term support for IA-32 and x86-64 will end in 2024<br />
|-<br />
|{{version|latest|[[Debian 11.0]]}}<br />
|Bullseye<br />
|14 August 2021<br />
|June 2024/2026<br />
|-<br />
|{{version|preview|[[Debian 12.0]]}}<br />
|Bookworm<br />
|{{TBA}}<br />
|<br />
|-<br />
|{{version|future|[[Debian 13.0]]}}<br />
|Trixie<br />
|{{TBA}}<br />
|<br />
|-<br />
| colspan="4" |{{Version legend}}<br />
|}<br />
<br />
[[Category:Linux]]<br />
[[Category:Operating systems]]</div>2.204.223.225