In Forum: Microsoft Operating Systems
By User: WinPC
In reply to Battler's post, I also have some ideas myself:
1. The Windows 8/Server 2012/Windows RT and post-Windows 8 builds that you mentioned. As you pointed out, we not only need a list, but also a way to separate the more likely builds from ones that are more doubtful (I myself know of at least two highly doubtful builds, both with the build number 9420), especially to prevent arguments over whether something is fake or real that are often started when the more likely and more doubtful builds are not properly separated.
2. Corrections to the checklist, such as the removal of confirmed fakes (remember "Windows Tokyo", anyone?), as well as a proper way to identify even builds that were faked shortly before and/or during the operating system's development (such as several early Windows 8 fakes such as Build 6519, version 7.0 Build 7504, version 8.1 Build 8000, etc...), as well as possibly even a separate section for all confirmed fakes, regardless of whether they also appear anywhere else in the checklist.
3. A way of viewing the checklist by each kernel, version, and stage of development.
For example, someone searching for information relating to builds of Windows 8-onwards would obviously not wish to wade through a whole entire list of builds of DOS, Windows 1.x, Windows 2.x, Windows 3.x, Windows 95, Windows 98, Windows Me (Millennium Edition), Windows NT 3.1, Windows NT 3.5, Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista and Server 2008, and Windows 7 and Server 2008 R2.
I know, that was a lot of words, believe me, but that's exactly what it all comes down to. There should also be a way of making it easier to view different versions of Windows side by side, and for exactly the same reasons. Not to mention that it also makes everything appear cleaner, and of course, there would still be a way to view the checklist in the old format at that.
4. An easier way to identify exactly which versions of each build are available, or at least have some level of information and/or other resources available, as well as whether the copy of the build released is complete, or whether it is incomplete.
For example, just because something might be available here, doesn't necessarily mean that it's available to every member here for every system that they might own. A good example is linuxlove - he installed the pre-release builds of Windows 7 in place of the RTM version due to not having a proper copy of Windows 7, and Rob Jansen quite understandably suggested that he install Build 7600.16384 rather than Build 7100, most likely due to the fact that it is very near the RTM level, and that the Internet Explorer 8 bug could just as easily be fixed by updating it manually.
But the problem here is that our copy was only available in the 64-bit version, which wouldn't run on his system that he was using at the time (at that time, even as recently as then, there were still a number of people who didn't own a 64-bit machine either, so 32-bit and 64-bit still often related to the system's hardware). He didn't have a 64-bit machine until at least late 2010, and it wasn't even until 2011 that he actually got a decent enough system that could reliably handle 64-bit software at that. I mean, it's not so much a problem now as it was then, since fewer people use older 32-bit systems, but still...
As a result of that and similar cases, I understand that similar situations regarding the exact version and counterpart could occur with the checklist, which is why I suggested making the exact versions that are actually available simply appear more clearly to the person who happens to be viewing the checklist itself. For example, listing each available version first, before listing anything else.
5. Merging the Client and Server versions of Windows from Longhorn (later Windows Vista) onwards - it indeed got very tiring to constantly have to add each build and each corrected and/or otherwise updated listing for a Client build to the Server listings and vice versa, especially when I had to make a clear distinction between whether the actual Client and/or Server counterparts were actually available here or not, as well as the counterparts for each article and screenshot, etc... Especially when it was all the same version of Windows anyway...
My idea is to just have one listing for all counterparts available for each more recent version of Windows (Windows Vista and Windows Server 2008, Windows 7 and Windows Server 2008 R2, Windows 8, Windows Server 2012, and Windows RT, and Windows 8.1, Windows Server 2012 R2 - unless Microsoft decides to use the Windows Server 2013 name, and again, Windows RT). That, in my opinion, would not only make the checklist cleaner, but would also make it easier to manage it, since you would not need to constantly make two entries for the same build, which makes absolutely no sense past the Windows XP and early Whistler Server (later Windows Server 2003) development period.
6. Finally, listings for alternative versions of operating systems that were otherwise mainly developed by Microsoft, based on Microsoft operating systems, or at least were originally developed by Microsoft, such as versions of DOS from other vendors (IBM-DOS - later known as PC-DOS, DR-DOS, Novell DOS 7, and Caldera OpenDOS to name a few), later versions of OS/2 that were entirely distributed by IBM, and third party versions of Windows (including not just third party builds and releases of Windows, including certain OEM versions, but possibly even ReactOS, which is based on mostly recreating the NT kernel, or at least something similar to it).
My post might be a bit longer this time, but I thought that it would be worth it, since you brought it up.