From BetaWiki
Jump to navigation Jump to search

We would like to ask you to follow these common practices for creating and extending BetaWiki content to prevent any possible conflicts.

Breaking or abusing the rules, depending on the severity, can result in either a verbal warning on your talk page or a temporary/permanent ban on administators' discretion. Your article might end up in the Hall of Shame if you don't follow the guidelines.

By editing on BetaWiki you acknowledge that you have read these rules and guidelines.

Common rules

  • Use your common sense.
The rules are not exhaustive. Do not assume that not forbidden automatically means allowed. We are not going to tolerate spam, vandalism, or abusive usernames.


  • Be civil to other users.
Always assume good faith, unless you have a very good reason and/or evidence to do otherwise - don't bite the newcomers. Personal disputes should be kept off the wiki.
  • Any unoriginal content should be properly accredited to the original source.
Don't copy content from other sites without providing at least a source URL.
Not everything is worth covering on BetaWiki.
  • Make sure that you link to the articles you create!
If you don't, the article will get lost and probably will lead to another one being made, for no reason. Unlinked pages can be found here: Orphaned pages
  • Use a single account to edit the wiki.
Any sockpuppet accounts created without previous approval will be banned, including the main account. This also applies if you create a new account and abandon the old one for a new username - if your account is at least 6 months old and you haven't already done so less than 6 months ago, you can ask a bureaucrat to change your username.
  • Try to avoid edit warring.
If you are engaged in a content dispute, raise the issue on the respective talk page and mark the page with the Dispute template. Administrators can protect pages that have suffered from edit wars.
  • Do not provide or request any links to download builds.
This wiki is only a knowledge base for these builds, and we will not provide these builds.
  • Do not provide links or instructions on how to crack software such as removing timebomb or bypassing activation. RTM product keys are also not allowed to be posted on this wiki.
The distribution of these cracks end up being usually illegal, so do not attempt to add them on this wiki.

User pages

  • Advertise only on your own user page.
Articles on beta community projects will be reviewed on a case-by-case basis.
  • Don't edit user pages of other users.
A very rare exception is staff removing inappropriate content.

Talk pages

  • Prefix new talk page threads with a header.
It makes an unnecessary mess from the page without these.
  • Sign your comments on talk pages.
If you want to be anonymous, make a user account, the signature will bear your username instead. Custom signatures, if used, must contain the user name.
  • Don't remove content from talk pages for reasons other than archiving or removing vandalism.
This does not apply to your own user talk page, as long as you don't remove official notices and/or warnings from our staff (if any).
  • Talk pages are not a private messaging service.
There are countless services for discussing off-topic and personal affairs. BetaWiki is not one of them.

Date formats

BetaWiki uses the day–month–year (DMY) "long" date format (e.g., 2 December 2020 or 2 Dec 2020) in articles. However, use of the ISO 8601 year-month-day (YMD) numeric date format (e.g. 2020-12-02) is also acceptable where space is limited, such as tables or infoboxes, but not within the article text itself.

The following table further documents the preferred date formats:

Acceptable date formats
General use Condensed Comments
20 November 1985 20 Nov 1985
20 November 20 Nov Omit year only where there is no risk of ambiguity.
N/A 1985-11-20 Use where space is limited, e.g. tables or infoboxes
November 1985 Nov 1985

Notability guidelines

There is a lot of software, and BetaWiki can't possibly cover every single version that somebody mentioned on the Internet. Therefore, we have a set of common notability guidelines to see if a subject is worth covering. They are not absolute, and we can make exemptions on a case-by-case basis for historically important subjects.

Applications and operating systems

An application or an operating system is considered notable if the product has been reasonably popular to the point that it has been covered by a reputable technology magazines (printed or on-line). This also applies to components of such products.

Operating system and applications mods are considered separate products, which also have to pass the notability criterion.

Software builds

Covering prototype builds and therefore researching the evolution of popular software is BetaWiki's main mission. A build is notable, if all following points apply:

  1. The product itself is notable
  2. The build has been sourced from a proper source
  3. The author of the source material is not considered unlikely to possess said version

The following sources are considered proper:

  • The build itself
  • A screenshot or video of the build that can be traced back to the original upload
  • An article about the build itself, or about its features, bugs, etc.
  • Internal documents, which have since then been made public

The following sources are also acceptable, if the build has been mentioned in more than one:

  • Warez CD list
  • Newsgroup discussions, comments, bug reports
  • Screenshots of download pages
  • File versions

A build is considered confirmed, if the source for the build is the developer himself, and thus there are no doubts about its legitimacy/existence.

We also cover fake builds in a limited fashion. A fake build is notable if in addition to the aforementioned criteria, the build has been considered to be real by reputable members of the community for a longer period of time, or has the potential to confuse new users about its legitimacy.


Aside from covering the actual software and its prototype versions, we also focus on tools that make using old betas easier, such as emulators, or unlockers of hidden functionality. These tools should of course be demonstrably used by the community in order to be considered notable.

Deletion policy

See BetaWiki:Deletion policy

Naming scheme


Windows <version> build <buildnumber> (lab)

The specification above is the most verbose one and isn't going to be used a lot. In most cases BetaWiki covers only one build with a particular build number, in that case the lab (if any) should be omitted from the page name. Use the name that's reported by the RTM build in the version field, i.e. NT 4.0, XP, 10. If the full build tag contains a lab name, make sure to create a redirect from the most verbose form above to the reduced form of the page name (without lab), i.e. Windows XP build 2428 (idx01)Windows XP build 2428.

In case there are several known builds with the same build number but from different labs, names of the pages should contain the lab name. To maintain a degree of consistency, the reduced name without a lab should be used for a disambiguation between the individual builds. If there are several known builds with the same build number that come from the same lab (i.e. are distinguished by the build date and time only), add the full timestamp to the lab component, i.e. Windows Longhorn build 4050 (private/lab06_demo.031019-1809).

For Windows versions that just used a major and a minor version number, use them in the version field and omit the buildnumber completely, i.e. Windows 1.04.

Don't mention the full update name for builds of Windows 10 updates, just use a plain numeral 10, i.e.: Windows 10 build 16179. On the other side, it's encouraged to make separate build listings for the individual updates, whose names should contain the official name of the update, i.e.: Windows 10 Creators Update. The YYMM update version should redirect to the full name, for example Windows 10 v1703 would redirect to the Creators Update mentioned before.


To make searching for build pages easier, BetaWiki maintains a couple more redirects aside from the ones mentioned above:

  1. If the build has got an official name, we should redirect it to the main page, i.e. Windows 8.1 PreviewWindows 8.1 build 9431.
  2. If there are more official builds with the same official name, redirect it to the main version page, i.e. Windows 10 Insider PreviewWindows 10
  3. The full buildtag, both including and not including the major and minor version must redirect to the main article, i.e. 6.3.9431.0.winmain_bluemp.130615-1214Windows 8.1 build 9431, 9431.0.winmain_bluemp.130615-1214Windows 8.1 build 9431. If there is a build number conflict between two versions of Windows, make a disambiguation at the conflicting redirect name.
  4. For already existing articles, the old-fashioned page name should redirect to the new page name for the purpose of not breaking old links.
  5. If the build calls itself by a codename, the combination of the codename and the build number should also be a redirect, i.e. Chicago 40eWindows 95 build 40e



Mac OS <version> build <build>

Mac OS X

version is meant to be the name of the particular release, i.e. Jaguar or Yosemite.

Mac OS X <version> build <build>
OS X <version> build <build>
macOS <version> build <build>



IBM OS/2 <version> build <build>

Microsoft OS/2 <version> build <build>

2.0 and later

OS/2 <version> build <build>


Infobox Windows build

See Template:Infobox Windows build

Infobox macOS build

See Template:Infobox macOS build



Use when the build you're posting also has an article on BA wiki, has a build page on TCB or has a gallery on TCB.


When creating buildlists, use the provided BLItem templates:
{{BLItem Confirmed|<article-title>|<buildtag>}} - use when the build was leaked, released, or we have another confirmation from Microsoft. Private leaks don't count.
{{BLItem Unconfirmed|<article-title>|<buildtag>}} - use when there is information avaliable, however no provided proof for it
{{BLItem Fake|<article-title>|<buildtag>}} - use when this build is fake, don't use if it's real and fake screenshots are also avaliable

When sorting buildlists, the first thing that matters is the build number. If there are several different builds with the same number, always sort them like this:

  1. winmain (& derivates like winmain_rtm or winmain_bluemp)
  2. partner recompiles (fbl_partner_out)
  3. other builds sorted alphabetically


Thanks to Foxlet for writing this!
In brief, all original screenshots should be:

  • Cut to the exact size of the subject (desktop or application window)
  • Saved in a lossless format such as PNG
  • Taken at a period appropriate resolution and color depth
  • Featuring a clean, original install of the product
  • Using default settings, unless the intention is to show the effect of a setting
  • Void of any custom graphics not included with the product itself

If possible, use the Windows screenshot feature (Print Screen key, Snipping Tool) to take pictures of the desktop, or use the screenshot feature if using a hypervisor/emulator. For "Full Screen" shots, if a cursor is present, it should be isolated in a corner of the background if possible (to show unique features of the cursor).

Article Screenshots

The desktop shouldn't be visible in application screenshots.

Each main article usually requires three components: the Desktop, the About window, and (sometimes) the Logo. In most cases, a build article only needs the first two. "Full Screen" shots (such as for the Desktop and Start Menu) should be 1024x768 in 16-bit color at minimum, unless the subject in question does not support such a video mode (for example, 1024x768 in 256 colors is fine for Windows 3.1 and early Windows 95 builds).

Screenshots must not use themes, wallpapers, or other graphics that are not included with the particular subject, even if they are "Demo" screenshots. Most screenshots should be taken with the default settings, unless the purpose of the screenshot is to demonstrate the effect of a setting. Screenshots should show the clean state after installation, without any extra installed software, unless they show a feature of the particular subject that cannot be demonstrated otherwise. Any personalization options can be reasonably demonstrated in a "Demo" screenshot in the Gallery. It is recommended to use a separate machine (virtual or not) with a clean copy of the operating system or application for the purpose of taking screenshots.

Desktop shots should be void of any extra windows, it should represent the state of the system when it is completely idle without any running programs. In the case that the OS shows a tool or special graphic (such as a welcome screen), that is known as a "First Boot" shot, and is separate from the Desktop shot.

Each article can also contain a Gallery, where other associated shots are contained. Additional full screen shots belong here, such as the "Demo" (which shows off particularly unique features of a build). The remaining shots are usually those of programs unique to a build. Those shots should be cropped to the size of the program's window (including transparency and window shadows if such effects are present). Child windows (if any) should be visible in their full area. The screenshots should be free of any watermarks, unless the respective build is unleaked and the only available screenshots are watermarked. Article screenshots should not be annotated in Paint or any other image editor, again the only exception is if there's no other screenshot available and the build is unleaked.

AeroShot is recommended for taking shots of programs under the Windows Aero theme.