To read all comments associated with this story, please click here.
Well a whole new UI that makes you work better and faster and more productive, plus touch functionality and gestures and massive productivity improvements and ease of use and entirely of new toolbar functionality and a new graphics improvements and API's such as directx 11/direct 2D and a new way to render text are pretty big things.
I didn't even mention the improved UI speed and overall performance improvement.
Redesigning existing services could also increase the thread count.
There's no cause-and-effect relationship between increase in thread count and new features. It just so happens that sometimes a new feature will increase the thread count.
Really? and you say this as a developer? Scary.
Unless you happen to know what microsofts policies for kernel development is there's no way you can know this fort sure.
Have you ever implemented anything that uses a pool of worker threads?
I can imagine Microsoft employees reading this and thinking that instead of actually doing any work they'll just change a "fooBarWorkerThreadCount" registry setting, and then call it Windows 8. I wonder how many people would see the dramatic increase in the thread count and decide there must be a corresponding massive number of new features...
I have to agree with you entirely. Thread count bares no relationship to new functionality whatsoever.
Recently I re-wrote some monitoring software from single threaded to multi-threaded. The threads were worker threads. There's an option in the software to adjust the size of the worker thread pool, so at any time without a single change of code I can increase this pool with zero new functionality.






Member since:
2006-12-22
As a software developer I am fully agree from the functionality that kernel thread count means a new functionality. Windows have a huge legacy and every subsystem that exists will have an impact on performance. 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.
Thom seems for me wrong (again as a devel) because the services of Windows cannot be removed without making some other to complain.
Thom shows anyway a logic that may be possible in Linux for instance (that's why it scales from mobile phones to super-computers) that you can remove functionality from kernel as much as you need to fit on your machine.
Probably the Windows Server 2008+1 will have the possibility to strip down the installations and the kernel, but I think is unlikely that persons wants to deploy one OS that will not give to you the guarantee that all you had yesterday you cannot run tomorrow.
Randall have right as much it knows the back of the development of NT kernel. Changing the policy of developing the NT kernel may lead that the thread measure is not right, but for now is really valid.