Just because you shout loudest does not make you right

Optimizations in algorithms and fixes will not justify enough to increase the version number.

Adding new subsystems to Windows will increase the thread count, so adding any functionality/services, major revamp to Windows will introduce new threads.

Optimizations in algorithms and fixes will not justify enough to increase the version number.

Changing the policy of developing the NT kernel may lead that the thread measure is not right, but for now is really valid.

So Randall accuses Thom on a couple of occasions of being a Windows fanboy:[quote]But then again, you're not really a journalist, are you Thom? You're more of a fan boy who somehow managed to secure himself a bully pulpit from which to spout his unsubstantiated blather.[/quote]That's news to me, and goes a long way in establishing credibility, or (as in this case) the lack thereof.

As a software developer I am fully agree from the functionality that kernel thread count means a new functionality.

But then again, you're not really a journalist, are you Thom? You're more of a fan boy who somehow managed to secure himself a bully pulpit from which to spout his unsubstantiated blather

Intersting that on the whole, OSNews readers seem to basically agree with Kennedy.

Infoworld readers seems to favor Thom.

http://www.infoworld.com/article/08/12/02/49FE-windows-7-great-deba...

(However, I do tend agree with Randall's assessment of Rock > Techno, but there's no accounting for taste )

The whole thing makes me think of power plants. If you were a power plant expert for the first half of the century, you'd notice a correlation between CO2 output and power produced at plants. Then The first Nuclear plant would be built and some industry stooge would declare that its an incredibly weak power plant, based on the C02 output.

Mark Russinovitch is a god among men when it comes to Windows development and I will always listen what that man has to say but now that he is on the MS payroll, his comments should be taken with a grain of salt as they can be slightly biased towards his employer, naturally.

his benchmark drives the UI at superhuman speeds and finds that it performs 40% slower. This has nothing to do with the Kernel as such and everything to do with the way GDI acceleration has changed (gone away!) in Vista.

While GDI lives in the kernel address space (win32k.sys) it's hardly a kernel subsystem

and MinWin can run without it.

I guess businesses should stay with XP... if they employ amazing robots who can type, scroll, and insert charts simultaneously at a rate of several operations per second.

Frankly, desktop applications (even "Enterprise" ones) do not stress the kernel's performance characteristics that much since the bottlenecks are usually elsewhere.

The other guy pretty much spent the entire time flailing around trying to change the subject, and throwing out personal attacks when he couldn't come up with an argument.

Mid way through a development cycle, (build 6801 is not even a beta), you are not going to be doing things like optimizing the thread pool size, so of course the count is going to be the same.

I don't pretend to understand kernel development, but I do have a high level understanding of MDAC and worker pools

enough to know that what he is saying is just silly.

When people use phrases like 'mid way though a development cycle' and 'not even a beta' it's because they know nothing has changed but they are insinuating that something will change later on. Using the "Oh we don't know what will happen" argument is just daft.

You don't go mucking around with kernel thread handling and integrity when you start releasing public builds the last I checked, especially when you have stated that drivers and applications will be completely compatible with a previous kernel version. This doesn't just mean binary compatibility, because you have to account for timing and all sorts of other extreme quirks.

In the absence of source code then we either go on hearsay as to what has changed, or someone looks at some evidence as to what has changed.

MDAC as in Microsoft Data Access Components.....?

The additional Local Procedure Call overhead of moving portions of MDAC (Microsoft Data Access Components) out of the kernel would most certainly be felt by a time-sensitive, looping transactional workload like ADO Stress.

" Mark Russinovitch is a god among men when it comes to Windows development and I will always listen what that man has to say but now that he is on the MS payroll, his comments should be taken with a grain of salt as they can be slightly biased towards his employer, naturally.

The more forceful something is claimed, it can be counter-argumented very easily when not backed up with enough facts (that are more useful than individual opinions in such kind of debate).