Justin A. Parr - Technologist

This post is in response to the following article:

“Why 7” by Mike Nash, 10/14/2008
http://windowsvistablog.com/blogs/windowsvista/archive/2008/10/14/why-7.aspx

Summary of the article: The successor to Windows Vista will be called Windows 7 because it is the 7th generation of Windows operating system. The internal “OS Version” will be coded as 6.1 for compatibility.

Thesis of this rebuttal: Don’t blame the developers! Mis-matched product names and versions introduces needless complexity, and is a recipe for confusion and frustration.

Windows version numbers (with the exception of Windows NT 3.1) have previously denoted product family and UI / API / kernel capabilities. I don’t think this was mentioned anywhere in the article, but I could be mistaken. A brief history lesson:

• Windows “1” and “2” were irrelevant. They had very little market share, and no applications. Windows really needed hardware-based multi-tasking in order to provide anything more than an attractive GUI for DOS. Windows “3.0”, paired with Intel’s 3rd-gen PC CPU, the 80386 (and later known as the i386), provided “protected mode” multi-tasking. “Windows” now had a use.

• Windows “3” includes the 16-bit products (Windows 3.0, its successor 3.1, and its network-aware cousin Windows for Workgroups 3.11), as well as the 32-bit products (NT 3.1, NT 3.5, and NT 3.51, which was really NT 3.5 + SP2). Toward the end of its life, there was an add-on to the 16-bit OS, called WinS32 that allowed you to run 32-bit programs (some NT 3.x programs) on WFW 3.11, including Freecell solitaire, but more importantly, TCP/IP. In “Windows 3”, only NT had a build number, but the minor product version number could tell you the capabilities of the product (with the exception of NT 3.1). Windows NT 3.x supported a 16-bit layer called “Windows On Windows” for running legacy Dos / Windows applications, but had a lot of compatibility issues.

• Windows “4” is all 32-bit capable, including both “NT” and the Windows 95 / OSR2 / 98 / SE / ME product line, based on a 16-bit boot loader, with a 32-bit shell / kernel, and a spiffy new UI, but still a distinct evolution of “Dos / Windows 16” and collectively called “DosWin”. The “NT” product line was also numbered and branded “4.0”, and included….. NT 4.0, which had 6 service packs during its 5 year run from 1996 until its successor, Windows 2000 in late 2000. Every version of DosWin 4 had a distinct build number, but NT 4.0 had (I think) 2 build numbers (maybe 1). I remember having to jump through hoops on NT 4.0 to determine programmatically whether a machine DID or DID NOT have a feature released in later service packs. The main differences between coding on DosWin 4 vs. NT 4 were based on sound / video capabilities (e.g. for gaming), and features only found in NT (e.g. NTFS, or advanced networking). Additionally, NT 4.0 had almost no support for external media and connectivity, such as USB or PCMCIA without 3rd-party add-ons, where DosWin OSR2 (Win 95 Release 2) and up did have native support for external connectivity. Generally, if you wrote a well-behaved, generic 32-bit app, it would run quite well under either DosWin 4 or NT 4, and would probably run much faster under NT. If you coded for performance or used OS-specific features, you would probably run in to compatibility issues, and thus as a developer you were well advised to have two “performance layer” modules: One for DosWin and a different one for NT. Both NT and DosWin supported backward compatibility with 16-bit and NT 3.x applications, but there was a likelihood that minor UI differences in the API could cause a SNAFU. Moving from the “Windows 3” interface to the “4.0” interface of 95 and NT 4.0 was a huge training issue, and a signficant cost, but not everyone had a PC on their desk (almost every worker has at least one PC today), and most companies bundled 95 or NT 4.0 training with training for “the internet” (Netscape) and corporate e-mail in order to help justify the cost.

• Windows “5” is Windows 2000. In the late 90’s, Windows 2000 started off being called NT 5.0, but was rebranded after a “development reboot” in 1998. Windows “Millenium Edition” (ME), the last of the DosWin product line, was dropped. Windows 2000 had yet another new UI from an API standpoint, but visually, it was similar enough to NT 4.o / DosWin 4 that no training was required, and programmatically similar enough that well-written NT 4 code would run generally without issue. The major concern about “Windows 5” was that many of the MINOR features and functions from DosWin 4 and NT 4.0 had been rearranged…. meaning you had to search for the new location of a particular function until you were familiar with the new layout (but still very little training required for the end-user: A savvy NT 4 users could jump in and start using Windows 2000 with ease). There were a lot of compatibility problems between NT 4.0 and 2000, primarily due to developers hard-coding a requsite for product “version =4” (in other words, poor development practice) instead of “version >= 4”. By the release of 2000, it was fairly rare to find an old WFW 3.11 or NT 3.51 machine, meaning that as a developer, you really had 3 platforms to support: DosWin 4 (if at all), NT 4.0 (The UI calls, IO interfaces, and shell features are different), or NT 5.0 (Win2k). If you wrote code that used the new features of 5.0 and intended to support 4.0, then you had to write a shim (compatibility layer) for 4.0 to include with your product.

• Then came Windows XP and Server 2003, which are numbered “5.1” and “5.2” respectively. From a coding standpoint, this is convenient because you only have to check the major version number unless you are developing something UI or feature-specific to XP /2003. This represents the first time since “converging” the product versions at 4.0 that there is now a split between “Server” and “Workstation” (also previously known as “Pro”), which also kind of made things convenient, but introduced a new kind of difficulty: You could code for “version>5” but future versions of XP / Server might be interlaced (e.g. 5.3 could be XP 2.0 and 5.4 could be 2003 2.0), and could have drastically different product capabilities. Still, the minor version increment between 5.0 and 5.x reflected the major UI / API / kernel compatibility bewteen all “5.x” versions, and how these various operating systems would handle your code. If you wrote code that directly accessed the hardware, or you wrote unsigned code, there was the caveat that your users would probably have a problem in 5.1 or 5.2 due to the increased security of those versions. Both XP and 2003 support “5.0” applications fully, and even some 2000 hardware drivers can be used by these systems (although not advised). Likewise, anything that runs on XP can run on Server, unless it is hard-coded not to work on one platform or the other. Both have a much higher degree of support for DosWin and 4.x applications than even their predecessor, Win2K. Until XP SP1 was released, Windows 2003 was a much better and more stable desktop OS than XP!

• Windows “6”: New product, new version. When Vista was released at version 6.0, it was anticipated that 2008 (Server) would follow the previous trend of being numbered “6.1” to indicate the high degree of compatibility and platform commonality between the two, yet underscore the discreet difference between a “workstation” and “server”. Unfortunately, the two operating systems are entirely different, but sport the same version number, “6.0”. If you check for “version >=6”, you still don’t know whether you are running on a desktop or a server (e.g. Do I display a “pretty” UI? Do I have DirectX capability? Can I run 16-bit processes?). From a legacy standpoint, developers had learned their lesson during the transition of NT 4.0 to 5.0. Most 5.x applications were theorized to run cleanly under Vista, only for the developers to find out that many API calls had been either disabled or removed from a “default” build (but some could be optionally added back), or even worse: fall victim to and trigger the dreaded UAC (or other artificial security limitations). None of these limitations are the result of poor coding practices. They are totally artificial limitations imposed by the operating system under the guise of “secure coding practices” and a “secure configuration framework”. The reality is that an incompatible app running as “System” would probably run just fine — except that Vista does not let the user interact with “system” processes. The major hurdle with Vista compatibility and acceptance by the vendors is that quite a bit of code may have to be changed even for a simple app to run, as compared to the “jump” from NT 4.0 to Windows 5, which in many cases only required a simple patch to disable the app from excluding “Windows 5” as a valid version number. From an end-user standpoint, companies are struggling with Vista’s significant UI and Shell differences because of the huge training costs involved. In addition, there is no real driver to go to Vista as there was to go from a “Windows 3” to a “Windows 4” platform, and a wide host of performance and app compatibility issues presents an additional barrier.

So, continuing this logic, “Windows 7” would be a new UI / API / Kernel platform. If vendors are struggling to upgrade their code to Vista (as evidenced by the lack of general vendor support for Vista and ’08), then re-tooling for a “7.0” platform would represent additional effort beyond what is already being incurred for the “6.0” platform.

Microsoft’s decision to call the new platform “6.1” indicates a general compatibility between 6.0 and “7”, and thus no REAL improvement from a platform standpoint. Likewise, I think the decision to name the product Windows 7 is driven by a marketing decision to distance it from the failures and difficulties of Vista.

Looking at the jump (from a development standpoint) from “5.0” to “6.0”, most of the development lessons had been learned from the previous jump to “5.0” from “4.0” — the OS itself and a new security approach is the real underlying reason for compatibility issues porting code to the “6.0” platform.

My thesis is that it does not make sense to call the product Windows 7 unless you are releasing a platform “7.0”, nor does it make sense to release a platform “6.1” and call the product Windows 7, somehow implying a new generation of features and functionality, when in reality the platform is just slightly evolved from “6.0”.

My opinion is that the author is laying the version / naming mis-match at the feet of 3rd-party development, when in reality, Microsoft can’t afford the time to re-code a platform “7.0” from the ground up due to all the UI / shell work that must be done in order to correct a phenomenally bad (and costly) user experience. If they do try to re-code from the ground up, they risk the same development “hell” that produced Vista, which included two full “development reboots” during the process. From time to time, you read articles about how badly the product development for Vista was managed, with UI and Shell teams having to be completely reactive to arbitrary decisions by the kernel team, with virtually no communication between the three.

Some background can be read here:
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html
This article describes one developer’s experience attempting to write a relatively simple shutdown routine, thwarted or disrupted time after time by changes in other areas of the OS, which resulted in numerous, unnecessary code re-writes.

It seems to me that Microsoft has a platform “6.0” with which they are satisfied, but are attempting to quickly recover from Vista’s utter failure. This is a valid business decision, and we would all like to see the “Vista” that should have been, rather than the bloated, slow, crapware that resulted from the previous development process.

However, let’s be clear about one thing: The decision to make the platform version 6.1 instead of 7.0 has NOTHING to do with compatibility for 3rd-party development.

Further, I believe the creation of a naming / platform version discrepancy is asking for trouble. I foresee the release of “platform 7.2” following 6.1, where 6.0, 6.1, and 7.2 are all really the same thing. Conversely, what will Windows 8 be? Maybe platform 6.2? Remember: We don’t want to cause problems for the developers….

Rather than relying on the platform’s major version number to determine its capabilities, developers will now have to rely on a “mental map” of which versions correspond to which platforms. Both development and support will be tedious and costly as a result.

Isn’t Microsoft really creating more of a future problem for 3rd-party developers rather than eliminating one, as advertised? I think the best solution is to drop the “Windows 7” name in favor of something else.

Product naming suggestions for “Windows 7”:

• Windows 6.1 (too confusing? I beg to differ: It doesn’t SOUND like Vista, and no one really knows what “Windows 6.0” is…..)

• Windows Nowhere (conveys the transition from having the panoramic view of a mountain to actually being lost on one)

• Windows Vista OSR2 SE R2 SP2 Improved Edition. (Nice and simple)

• Windows Aspire (we can rename Vista to Windows Regret or Windows Recall)

I implore Microsoft to please reconsider the name “Windows 7”.

And while you’re at it, please quit hyping Vista: WE know it sucks, and YOU know it sucks, so let’s just get past it, and get a better OS option out there. Towing the “company line” that Vista is the best option slowly erodes your credibility, and you’re not selling your customers the product that they want. Instead of continually recommending that companies “switch to Vista in order to realize the benefit from all of Vista’s new features”, how about something more realistic: “We recommend you maintain software assurance on all Microsoft products in order to benefit from exciting future updates and releases.”