Mark Russinovich: Inside Windows 7 | Going Deep

ZippyV
Fired Up

I know it's offtopic but I've got a question about the Sysinternals tools: when will we get an updated version so that they work decently in Vista (like rootkitrevealer)?

vesuvius
Das Glasperlenspiel

Fascinating...In the true sense of the word!

stun

This was a really amazing cool interview !!! I loved this interview.

I wanted to ask one thing tho...Any word on the WinFS?

Is it going to see the light of the day in Windows 7?

Or has it been abandoned?

Or moved somewhat under the next version of Microsoft SQL Server?

Or what happened to it?

sokhaty

So, it sounds like there won't be .NET framework sub-set on Win2008 R2 Core (and consequently no PowerShell 2.0 either), is it a correct assessment?

sysengineer
http://www.itedge.net

In reply to ZippyV

#Oct 28th, 2008 @ 1:06 PM

the updated tools are only available through the Microsoft Desktop Optimization Pack (MDOP). MDOP is an add-on subscription to Windows Client Software Assurance. MDOP also contains a lot of other cool tools like Application Virtualization that used to the the Softricity SoftGrid product.

dtzar
extreme

In reply to ZippyV

#Oct 28th, 2008 @ 1:06 PM

Mark also talks about the next version of Sysinternals in the interview I did with him on TechNet Edge:
Interview with Mark Russinovich: the future of Sysinternals, Security, Windows

Charles
Welcome Change

In reply to sokhaty

#Oct 28th, 2008 @ 2:24 PM

Actually, R2 will contain PowerShell as an optional install. Read about here

C

sjh37
Software should not break. It should just work. Forever. No matter what...

I'd like windows to not do a context swtich on a thread when its doing disk i/o. i want it to hold onto the thread for say 500ms, instead of 20ms as this gives the disk more time to read/write.

If each thread is accessing a file, the whole thing slows down to a crawl as the hard disc read head has to jump to each file every 20ms. It would be MUCH better if the operating system could allocate more time to read a file before it allowed a context switch. say 500ms. that would allow more data to be retrieved from the hard disc, less head thrash, less time waiting for the head to move, and performance would go up greatly.

Just try creating 2 or more zip archives at the same time, then time it again but only doing 1 at a time. Winrar has a feature where it will wait (probably using a global mutex) for other winrar windows to finish before the next one starts.

You can context switch CPU threads till the cows come home, but a phsical device needs more time to read/write when the head arrives.

BitCrazed

In reply to sjh37

#Oct 29th, 2008 @ 7:34 AM

IO is extremely costly. In most cases, if a thread requests an IO operation, it's going to be hanging around for quite a while for the IO to complete, so it makes sense to curtail the thread's quantum and move onto the next thread awaiting CPU time (i.e. context switch).

When the IO operation returns (most likely a DMA operation these days), the CPU will be interrupted and the interrupt handler fires, unblocking the interrupt service thread (IST) and releases the CPU. The CPU then works out whch thread to run next. Because the IST is a high-priority thread, it'll most likely get the next quantum and complete the IO operation. Your IO requesting thread will then be reactivated and return.

Forcing the IO requesting thread's quantum to extend (to HALF A SECOND???) will only slow down the machine as the CPU will be able to execute FEWER threads per second because of the largely dormant thread hogging the CPU's time.

The reason that creating two Zip archives simultaneously mgiht be is slower has many factors, including the rotational, seek and data transfer capabilities of the storage device itself, how fragmented your storage device is, whether your device implements some kind of write buffering, etc. And that's not to mention whether you're running single/multiple processors and what else is running on your box.

If it takes longer to create two zips at the same time vs. doing it serially indicates to me that you may be suffering from slow disk and.or high disk fragmentation forcing your Zip tool to create and extend its file in many small chunks, causing lots of disk seeking and therefore slowing you down.