Flame war: The great Windows 7 debate

InfoWorld's Randall C. Kennedy and OSNews' Thom Holwerda go head to head over how to assess Windows 7's changes

Not a day goes by in which InfoWorld fails to receive a flaming comment or e-mail attacking InfoWorld's Enterprise Desktop blogger Randall C. Kennedy and his recent analysis of the pre-beta version of Windows 7. As time goes on, it gets more personal. Recently, I received this little gem: "Randall C. Kennedy is a jaded, personally hurt, pathological liar who only does a disservice to your Web site."

What could cause such invective? The article that really poked the hornets' nest was "Windows 7 unmasked," in which Randall lays out his argument that Windows 7 is a simply a point rev of Vista. The attacks came fast and furious. How dare Randall benchmark pre-beta software? How could he possibly draw conclusions based on the evidence he presents?

[ Randall C. Kennedy is not gentle with the pre-beta version of Windows 7. Check out his arguments in "Windows 7 unmasked." ]

Several of Randall's detractors have pointed to a critique written by Thom Holwerda, managing editor of OSNews. It was held up as a smackdown and, as it turned out, it was also well written. So what else could we do but invite Thom to debate Randall one on one?

Thom graciously agreed. The ground rules for this e-mail debate were simple. Each message would be of reasonable length. Changes of subject would not be used to circumvent points of disagreement. And both parties would avoid descending into name-calling or profanity. Otherwise, we would not edit the exchange, except to correct spelling or grammatical errors.

I think you'll enjoy the results on the next pages. You'll find more light than heat here, although the discussion is spirited. And while it helps to know something about the inner workings of Windows, both Thom and Randall keep their arguments clear and jargon-free. As Thom says in the final line of the debate: "It's up to the readers to decide which of us is making more sense."

--Eric Knorr, editor-in-chief

Randall to Thom:
The kernel count is in fact a good indicator, if not used in isolation

After reviewing your "rebuttal" article, I find that you seem to agree with the core point of my original piece: "In all seriousness, Microsoft has been very clear that when it comes to under the hood, there won't be many changes between Windows Vista and Windows 7. There will be optimizations to improve performance, but nothing drastic."

So, now that we've established that we both agree that Windows 7 is not a major upgrade to Windows Vista (at least as far as "under the hood" is concerned), we can move on to the first major objection in your "rebuttal" text:

"First of all, the number of threads running within a kernel says absolutely nothing whatsoever about how many changes have or have not gone into the kernel ..." (Note: I preserved the emphasis on "whatsoever" from your article.)

Wow! That's a bold statement for someone who (I would assume) does not have access to the Windows 7 source code! The truth is that, without walking the NT kernel source tree, there is simply no way to conclusively make such a statement one way or the other. That's why, in my article, I make a point of establishing the history of this metric and how -- over the 16 years I've been working with the NT code base -- it has proven to be a good, externally accessible indicator of kernel churn.

So my response is: There is no way that either of us can state conclusively that the thread count metric does or does not express change at kernel level. But then again, I never claimed that it does -- only that history shows the value changing significantly from major version to major version. Combined with various statements made by Microsoft on the subject, this lack of change -- when viewed in the context of the aforementioned history for this metric -- would seem to support my own conclusion about Windows 7 being so similar to Vista as to warrant a "point release" or "R2" moniker. A conclusion, I might add, that you have already tacitly agreed to (see first quote above).

Careful with those "absolutes," Thom. You'll find they have a habit of painting you into a corner. :-)

Thom to Randall:
It's your method that I believe is flawed. Here's why

We do not differ on your conclusions per se, but on the methods and data that you based your conclusions on. I don't know if you could call Windows 7 a major release -- I think that a massively reworked interface and a system-wide multitouch framework that all applications automatically make use of already justifies the "major" moniker, but it's obvious that compared to XP-to-Vista, Vista-to-Windows-7 isn't as long a leap.

The problem is that the "thread count" metric is flawed -- it is flawed today, and it was flawed 10 years ago. I love analogies, and looking around my living room (as I listen to The Police's Zenyatta Mondatta on LP), let's take my LP collection as an example. I don't know the exact count, but I have about 200 LPs. It's a nice collection; mostly old stuff that I inherited from my parents (since I have an LP player and they don't).

Let's assume I'm going on a buying spree tomorrow. I buy 20 new LPs, so now I have 220 LPs. However, I also sifted through my collection, and found 20 LPs that are too scratched to listen to comfortably -- so I throw those out. So, now I'm back to the same old 200 LPs.

Let's say you run LP-Infoworld.com and you monitor the various LP collections in the world. You are standing outside my window, and you counted the number of LPs yesterday, and you do it again after my buying/removing spree. You are standing too far away to notice the specifics of each LP, but your count remains the same: 200. From this, you draw the conclusion that my LP collection is still the same, and that nothing has changed -- despite me buying 20 new ones and throwing out 20 old ones.

It doesn't matter whether this analogy takes place 10 years ago or today. Counting the number of threads, or LPs, doesn't tell you anything whatsoever other than -- surprise -- the number of threads (or LPs) in Windows (or my LP collection).

I never made any absolute claims, as you did in your statement: "Windows 7 = Vista because the number of threads is similar." I don't contest that the number of threads is the same, nor that Windows 7 = Vista. I contest that you arrived at this conclusion based on nothing but counting threads.

Randall to Thom:
The kernel count metric is not "empty," and threads aren't interchangeable

The flaw in your analogy is that you're assuming you can simply interchange kernel functionality like you can swap LPs -- except that to do so in NT's case would be to irreversibly change the aggregate "tune" of kernel "collection," with the net result that legacy applications and drivers would start breaking all over the place. So any such changes to the collection would have to be extremely subtle so as not to fundamentally alter the "beat." Which is exactly how I'm describing the Windows 7 kernel changes, which were so minor, the Windows core team assigned Windows 7 a point release moniker (i.e., Windows NT 6.1).

To expand on your analogy, any attempt to significantly increase the functionality of the NT kernel would require more than a reshuffling of the LP deck. It would necessitate the introduction of new LPs (threads) to support this expanded capability while maintaining the existing collection mostly intact in order to preserve the original tune (i.e., backward compatibility). Clearly, this has not taken place with Windows 7, but would almost certainly need to take place in any major OS update that continues to support legacy code.

Which brings me to my second point: You're dismissing established precedent. Every major update of the NT kernel has introduced additional threads in support of the new functionality provided. So while thread count may not be conclusive proof that only minor changes have taken place, it's a heck of a good place to start looking. And in the case of my article, that's exactly what it was: An empirical starting point that helped me quickly establish a set of assumptions (i.e., Windows 7 = Vista R2) that I then sought to further qualify through additional analysis and testing.

But I can understand your confusion. To the untrained eye, the kernel thread count metric may seem empty. But to someone who was working with this platform professionally while you were still finger painting in primary school, it says an awful lot. It tells me this is a minor, as opposed to major, update. It tells me that, barring a complete dismissal of legacy compatibility, no significant new functionality has been introduced. And it tells me that any performance optimizations made will deliver, at best, modest gains -- a supposition I later proved during benchmark testing.

BTW, I hope that LP collection of yours includes at least a few classic American bands: Boston, Aerosmith, Led Zeppelin. Maybe a little Tom Petty. Please tell me you're not into techno or some kind of Euro-trash fluff. That stuff's a waste of good rack space. :-(

Thom to Randall:
Aha! You fell into my logic trap: Win 7 has better threads, despite the static count

My analogy isn't flawed. It's merely designed to be incomplete, so that I could lure you into the trap described below.

Who said anything about interchanging LPs? You assumed interchanging, but I might have bought the exact same worn-out 20 LPs I threw out! I would get better sound, less static, no skipping … my world wouldn't change and turn pink with ponies and rainbows all of a sudden, no, but I would get a much more pleasurable listening experience.

And counting my LPs still wouldn't reveal those improvements.

Mark Russinovich clearly explained all the work that has gone into the NT kernel between Vista and Windows 7. For instance, they greatly improved SMP [symmetric multiprocessing] by doing some major work on the dispatcher spin lock, enabling the kernel to scale up to 256 processors. Another one is the cleaning of the core Windows components to eliminate calls that travel up the stack, enabling them to create a relatively bare-bone Windows installation. This installation carries only the most basic functionality (the NT kernel, the executive subsystems, the memory manager, networking, and optional file system drivers), and is referred to as Cutler's NT by Russinovich (or, on the Net, as MinWin). Since there are no upward calls, Microsoft can make changes to these core components without affecting anything higher up the stack -- allowing for easier bug fixing and performance tweaking.

MinWin isn't "done"; the elimination of upward calls is still under way. Microsoft is untangling the intricate web of dependencies inside Windows as to make future changes smoother.

I would call these two elements alone (and there's more, like improvements in the memory manager) definitive and tangible improvements made to the kernel -- and yet, your thread-count statistic doesn't show it. And if your thread-count statistic doesn't reveal even such fairly massive improvements, how reliable and useful of a statistic is it?

That's my point regarding the thread count. The fact that thread count seemed to go up more during previous major releases doesn't prove anything -- it doesn't prove a causal relationship in either direction. You'd need a lot more proof to make me see thread count as an indicator of anything more than just ... the number of threads.

An increase in threads may indicate a performance loss (more complexity). It may indicate a performance gain (optimizing for multicore/SMP). A decrease in threads may indicate a performance gain (less complexity). It may indicate a performance loss ("deoptimization" for multicore/SMP). The statistic alone really, really doesn't mean anything.

Randall to Thom:
Those Win 7 kernel changes have limited real-world effect

Your analogy is still flawed. Code isn't like the surface of an LP. It doesn't degrade over time, nor is there any way to improve its quality without changing it. Which puts us right back at square one: Change the code and you change the tune, which risks destabilizing the whole ensemble.

At this point I think you should probably abandon your LP analogy since it simply doesn't work and you've clearly taken it as far as you can. Or stick with it and I'll keep poking holes. It's your call.

Back to the matter at hand: You claim kernel thread count doesn't matter. I claim it does. I point to historical precedent and benchmark data. You counter with more speculation and then fall back to your flawed analogy.

You know, Thom, just repeating your position over and over again won't make it suddenly become true. You can't invent a major Windows kernel update where none exists. And no, Mark Russinovich's latest interview won't help you. Mark makes it clear that the majority of changes to the shared Windows 7 client/Windows 7 server kernel won't be felt outside of the datacenter. So while it's cool in an academic sense, it has little bearing on the real-world performance characteristics of desktop PCs.

Since this line of discussion is clearly going nowhere, I suggest we switch gears and focus on another area you touched on in your rebuttal article: benchmarking.

In your article you say, and I quote: "Vista was a dog when it was first released, but these days, after lots of patches, fixes, and a service pack, it's actually quite snappy."

My challenge: Prove it.

Seriously, if you're going to criticize me for supposedly making unsupportable statements about Windows 7, I'd like to see you defend your own statements. Show me your data that proves that Vista's performance has improved measurably since RTM. I've got reams of results to the contrary, so by all means, let's see what you've got.

BTW, pink ponies? Rainbows? Must be the techno -- it's messing with your head. I strongly advise a strict regimen of classic American rock 'n' roll. Begin with Side 1 of Boston's eponymous debut album ...

Thom to Randall:
Whatever you think of Win 7's changes, your thread count metric misses them

It is wholly and completely irrelevant to the discussion at hand whether or not a certain change in the kernel only affects certain customers, but not regular consumers. Even if a change affected only Major Tom, the end result is still that your thread count metric should notice it. Seeing that it doesn't notice the changes that I highlighted, it seems pretty clear to me that your thread-count metric is flawed. That's just my opinion, though. We'll see what our respective readerships think.

This is unrelated to whether or not the changes that I mentioned really are, as you say, relevant only to datacenters. The improvements made to the kernel that allow it to scale up to 256 processors are bound to be accompanied by changes to SMP in and of itself, which most certainly does affect basically every newly bought computer today (apart from the mobile Intel Atom, are there even single-core machines being sold?). Changes in the memory manager obviously affect customers, too, since memory management is one of the most basic and important functions of a kernel.

But the change that is most certainly going to affect every user of Windows is MinWin (by lack of a better name). By eliminating upward calls and by untangling the web of dependencies in the very core of Windows, Microsoft will be able to make changes to these core elements in an easier fashion, without causing as much breakage in parts higher up the stack. I don't know in what possible universe that is not seen as an improvement. This could benefit every user -- maybe not right away, but it will, in the future.

Let's move on to the next point you wish to discuss. I'll be clear: I don't need to prove that Vista's performance has improved between RTM and now. Others have already done so for me, and I trust those people a whole lot more than my own perceptions.

For instance, a major source of problems during Vista's early days was the instability and immaturity of Vista's graphics drivers, which needed to conform to a new driver model (compared to XP). Benchmarks suggest that these problems have been ironed out, and that Vista's graphics performance has increased (as of SP1) to the level of Windows XP -- this was written in May 2008, and we've already seen more updates and fixes since then.

Another much more detailed and elaborate benchmark comes from AnandTech, which professionally benchmarked Vista SP1 after its release, and concluded that it improved boot/shutdown times and fixed the extremely aggravating and utterly brain-dead "file copying bug," a bug that contributed to a large degree to the overall feeling that Vista was slow. They also note that Vista's performance had improved steadily during the first year after its release, with bug fixes, patches, and other updates.

There are countless other reviews and reports that clearly state that Vista has improved over time, but I won't detail them all. These articles are mostly published after the release of SP1, so they do not take the patches and updates since then into account. These are just some random plucks off the Net; there are many more.

Add to this my own personal experiences -- I run Vista on my Aspire One netbook these days, something which would've caused me nightmares during the RTM days. In addition, even some of the most avid Vista detractors on OSNews have admitted that Vista has indeed seen performance improvements since its release.

I'm ready to move to the next point on your list.

Randall to Thom:
Win 7 performance tests show it's the same as Vista -- so where's the change?

On the subject of benchmarking, if you take a moment to step outside your personal experience space of gaming and enthusiast computing, you'll discover that real-world performance means more than frame rates and 3DMarks. It means the ability to process potentially complex workloads efficiently and without undue penalty from the supporting operating system.

This is why Windows XP has lingered so long in enterprise computing circles, while Vista has been soundly rejected: Because Vista placed such an undue burden on systems that it made it nearly impossible to support the complex workloads that make up the typical enterprise computing stack.

Simply put, it overwhelmed the hardware available at the time of its launch, forcing customers to choose between wasting CPU upgrade cycles on superfluous features, like DRM and content protection, or putting them to work improving the performance and end-user experience of their business-critical applications. And I think we can all agree on where IT decided to focus those finite resources.

Here's a statistic for you: At a fundamental level, Windows Vista is 40 percent slower than Windows XP on common business productivity tasks.

This isn't conjecture. It isn't speculation. It's cold, hard fact based on extensive testing of both OS and their respective recent Service Pack iterations: Windows XP Service Pack 3 and Windows Vista Service Pack 1.

Here's the original research work that backs this up: "Vista SP1 a performance dud," "Windows XP SP3 yields performance gains," and "How to make Vista run like XP (sort of)."

Note that I say "at a fundamental level." The truth is that, if you strip away all of the Vista features -- disable all the new services (Search, SuperFetch, MMCS), turn off all the new UI goodies (Aero, compositing), and terminate every noncritical process -- Windows Vista is still 40 percent slower than Windows XP. In fact, no matter what you try, you will never manage to tune Vista so that it performs like Windows XP on identical hardware. Never. It's simply not possible.

Why? Kernel complexity. Those extra 39 to 41 execution threads (96 to 97 versus 56 to 57 on XP) translate into a kind of performance anchor around Vista's neck, causing even a stripped-down, bare-bones implementation to perform at degradation levels that approach disabling a core or drop a gigabyte or two of memory. It's why XP is roughly 18 percent slower than Windows 2000 (due to its 22 additional kernel threads). And it's also why Windows 7 performs almost identically to Vista (no significant increase in kernel complexity -- yippee!).

In fact, if you look at the history of the NT kernel, and you map the increase in thread count against the decrease in performance (relative to the previous iteration), you come up with a nice little ratio that fits the data almost perfectly: For every additional execution thread added to the kernel, linear performance decreases by 1.0 to 1.2 percent.

Again, this isn't speculation. It isn't conjecture. It's an observation made over several generations of the NT OS, a convenient rule of thumb that has yet to be disproved. And I do hope that both our reader communities will accept my not-so-subtle challenge to disprove the kernel thread rule by downloading the free tools and resources of the Windows Sentinel project.

Some more raw data to put things into perspective: the exo.performance.network's iWorldTest community benchmarks and "Fat, fatter, fattest: Microsoft's kings of bloat."

So, to wrap up today's lesson:

1. Performance means more than gaming and gamer-centric benchmarks.
2. Vista is measurably slower than Windows XP at a fundamental level, just as XP is slower than Windows 2000 at a fundamental level.
3. Techno sucks -- long live rock 'n' roll!


Thom to Randall:
Vista isn't the issue; thread count is the issue. And you're off base on MinWin

You're not going to get any counterarguments from me regarding the fact that businesses and large enterprises won't like Vista over XP. Vista obviously requires better hardware than XP, and it may certainly perform slower than XP in some, or many, workload scenarios that are important to businesses.

Meaning they will have to spend more money to get the same results, and that makes no sense.

However, that's not what our two original articles were about, and it's most certainly not what our current point of debate -- Vista's improved performance over time -- is all about. So while you may have a good point on Vista requiring more hardware, or performing worse on the same hardware than Windows XP does, it's irrelevant to this discussion. We're comparing Vista-now to Vista-RTM -- not to XP.

But I see we're getting back to the thread-count point. I'm afraid we're going to lose our readers this way. I continue to stick by my original point, namely that the number of threads says nothing about the amount of changes made to the kernel. Like I detailed before, any change in thread count could lead to any possible outcome -- increased or lowered performance or simply no gain or loss at all. The fact that your thread-count metric did not pick up any of the significant changes detailed by Mark Russinovich and Eric Traut clearly shows how useless a metric the thread count statistic is. That's going to be my final word on thread count, as we have both done our thing. Let's leave it up to our readers to decide which argument makes more sense to them.

Let's move on the next point on the list, and this time, I'll pick one.

How is it possible that someone who claims to know so much about the NT kernel appears to be so blatantly ignorant about the concept of MinWin, even though both Traut and Russinovich detailed the concept in such a crystal-clear way? Let me quote my own article:

"Kennedy is so wrong about MinWin, I'm again at a loss as to where to start. Despite a number of fairly clear explanations from Microsoft (most notably, by Mark Russinovich), Kennedy shows a clear lack of understanding on what MinWin actually is. Microsoft never promised a 'clean break'; it never promised a 'new kernel.' Microsoft has been very clear: MinWin is not a new kernel. It is not a streamlined NT kernel. In fact, it is the NT kernel. The only thing Microsoft did was reorganize parts of it to make it cleaner, and to make sure they had a small core without any outward calls, so that they could make changes to the Windows kernel without causing massive breakage."

I'm very interested to hear about where you got the clean break and new kernel stuff from. Really, I am.

Randall to Thom:
Sorry, but the MinWin criticisms are simply wrong, based on misreading what I actually said

I was waiting for the MinWin topic to come up. Never in my 20-plus years as an author, analyst, and software developer have I seen so many make so much out of so little: a single sentence, taken out of context and without regard for anything I had written before. Yet the Windows fanboys pounced, thinking, "Aha! We've got him!"

Well, time to burst your bubble on this one. Please take a moment to review this Windows Sentinel blog entry -- posted by yours truly -- way back in June 2008.

Note the title: "The myth of 'MinWin' and a thinner Windows 7."  As you can see, I was the first major media pundit to report on the fallacies surrounding the MinWin hype. In that post, I explained why replacing the Windows NT kernel with something newer and lighter was impractical, and how those who believed in such a creature were speaking out of ignorance and/or were misinterpreting the Eric Traut demo. In point of fact, I believe you actually linked to this piece from OSNews.

Regardless, at the time that I published the above blog post, people were already calling me a quack. Not for believing in a clean break with Windows 7, mind you, but rather for denying such a break would occur when so many were reporting the opposite. The simple truth is that I was publicly chastised five months ago for not drinking the media-hype-fueled MinWin Kool-Aid. So, for these same zealots to now accuse me of being somehow "confused" on the issue is both disingenuous and, in the case of my regular readers, downright slanderous.

But hey, an opportunity is an opportunity, and if your goal is to discredit someone at any cost (the true mantra of the zealot), then any gaffe -- even a fabricated one -- is simply too good to pass up. That you and your compatriots seized on this one sentence and sought to turn a molehill into a mountain speaks volumes about your agenda.

Note: If you were trying to be objective -- and I think we've established that objectivity was never your goal -- you would have looked into my larger body of work on the subject before rushing to judgment. At least that's what a real journalist would have done. But then again, you're not really a journalist, are you, Thom? You're more of a fanboy who somehow managed to secure himself a bully pulpit from which to spout his unsubstantiated blather.

Bottom line: It was to these users -- the original MinWin true believers and anyone they may have inadvertently influenced -- that my comments in the latter article were directed. I was speaking to the confused masses and reality-deniers to whom "MinWin" still meant "new kernel." My goal was to prove to them, once and for all, that Windows 7 was indeed based on the Vista kernel architecture -- not some new "clean break" kernel that they may have heard about during the months of rampant hype and speculation leading up to the PDC.

In conclusion, I'll leave you with the following quotes from one of those confused media types who inadvertently misled so many. Speaking about Windows 7 and the Eric Traut demo, this person opened his analysis by saying, "First up is a streamlined microkernel codenamed MinWin, around which a re-engineered Windows line will be built." And later, in the same -- or a related -- article, they repeated the fallacy: "Additionally, the presentation also showed us that Microsoft is in fact working with a stripped-down, bare-metal version of the NT kernel, to be used as a base for future Windows releases."

Sound familiar? It should. It's you, Thom, in one of your own articles posted to OSNews.

So, tell me all about this "streamlined microkernel" you reported on. I'm dying to hear details ...

Thom to Randall:
It's you who's misreading my comments. Sounds like you're pulling a Dvorak

If we are going to turn this into a contest about who was first to claim that the Windows kernel didn't need to be replaced, I've got some bad news for you -- because I've been saying that in various articles for a long time now. The earliest article I could fine is one I wrote 18 months ago. Several followed.

And no, you most certainly weren't the first to report on what MinWin actually was. Not by a long shot. Looking at OSNews, this is what we had to say when Eric Traut's demo first made its rounds on the Net: "First up is a streamlined microkernel code-named MinWin, around which a re-engineered Windows line will be built. Described as 'the Windows 7 source-code base,' in reference to the successor to Windows Vista that is slated for a 2010 release, MinWin strips back the current NT-based kernel to the barest of bare metal."

You took that first sentence out of context, by not linking to the original news item it was part of. As you can see, we clearly explained this was a stripped-back variant of the NT kernel, which is an accurate depiction. This was well over a year ago. We again made this clear, along with several other Web sites, on other occasions, all well before your five-month mark. So, no, you're not the first person to report accurately on MinWin.

But again, you're steering away from the actual matter at hand, which is that in your "Windows 7 unmasked" article, you misrepresent what MinWin is supposed to stand for, even though you claim to be the first to accurately explain what MinWin is. Which raises the question -- why would you suddenly proclaim an understanding of MinWin that you claim to have been debunking earlier?

From my conversations with you over the course of the past few days, it has become more clear than ever to me that I already answered this question myself in my original reply to your "Windows 7 unmasked" article: No, you're certainly not clueless, and yes, you certainly know what you're talking about. This leaves us with the only possible option: You did a John Dvorak. You are writing all this nonsense merely to attract readers, and then, when these readers call you out on your bull****, you claim they are all Windows zealots.

Classic Dvorak behavior. Your latest article confirms this trend -- you made up a fake claim about Microsoft supposedly delaying the Windows 7 beta to next year, even though this was clearly the company's target all along and they have never made a promise otherwise. [Editor's note: Randall intended that post as a joke, but many people didn't get it.]

This is the last e-mail on this debate. We promised the editor-in-chief of InfoWorld this debate would be civil, and without any personal attacks, and I think that at least I have remained true to my word. Now it's up to the readers to decide which of us is making more sense.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies