The Advancement of Windows: Narayanan Ganapathy - Windows Vista IO | Going Deep

From the kernel to the shell, Windows Vista is a very different OS than XPSP2. How so?

Here, Charles interviews Architect Narayanan Ganapathy whose team of highly skilled engineers write the Windows IO system, driver frameworks and related technologies. So, what, exactly, is new in Windows Vista with regard to IO? What does it mean, exactly, to users and developers?

Tune in. Learn.

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

ZippyV Fired Up

Sep 29, 2006 at 4:17 PM

I know Windows is not a realtime os but why does it have the 'realtime' thread priority? When and why should this priority ever be used?
DigitalDud

Sep 30, 2006 at 12:01 AM

ZippyV wrote:

I know Windows is not a realtime os but why does it have the 'realtime' thread priority? When and why should this priority ever be used?

I've also seen it called "critical" priority. I think it's basically saying "this isn't realtime but its as close as you're going to get."
Hakime

Sep 30, 2006 at 2:25 AM

From the video: "Vista the most advanced general purpose OS"!? I really don't think so, please look at the market!!!!!
littleguru <3 Seattle

Sep 30, 2006 at 4:03 AM

Nice video. It's great to see that the hungs (because of IO) are finally targeted!
Lon^

Sep 30, 2006 at 7:01 AM

I'll second that about the hung I/O, it’s so incredibly annoying when you click a cancel button and nothing happens! It’s just unfortunate that in order to use it you would have to throw away XP compatibility but in a few years when everyone is using vista this shouldn’t be a problem.

As far as user mode drivers, I've moaned about this before but understand that as Charles says for an input device its really not going to matter and will improve stability etc. It’s not going to matter for your mp3 player because presumably you’re only going to upload a few files to your iPod etc and then close the tool so CPU usage here is irrelevant.

If on the other hand I am playing a game and I want to write stuff out to the display then I really want that to be as fast as possible. Any more CPU power I get including more cores etc I want that devoted to the game and not to drivers. Take Alan wake for example, its going to use four cores.

I can definitely see the argument for reliability over speed for business use, you would rather have all user modes there but in a gaming environment I would rather spend time buying hardware that I know has solid kernel mode drivers and then get the speed. Maybe two versions of the OS are required, one for gaming that is streamlined to have less background services e.g. no indexing etc, basically the gaming OS would be streamlined to run one game as fast as possible (like the Xbox and 360 OS's). You could then have a business version with all the great features mentioned in the video. With the coming of hardware virtualisation (run both versions at the same time) and more and more people having many machines in the home maybe this won’t be an issue in times to come.

Anyway enough of my rambling thanks for the interview
Nar Ganapathy

Sep 30, 2006 at 7:39 AM

There are many scenarios and some of them are given in the "Inside Windows" book. For example, many critical system threads run at real time priorities. Using these priorities require "increase scheduling priority" privilege.

For further details I would recommend the "Inside Windows" book.
earnshaw Jack Sleeps

Sep 30, 2006 at 2:27 PM

Thanks very much to Nar for the excellent discussion. I was thinking how Channel 9 audio could be improved: wireless mic. The interviewee clips on a wireless mic. It is a radio transmitter. Charles runs a radio receiver which plugs into the video camera. Then, instead of picking up the speaker's voice plus all the ambient noise and echo, we hear the speaker's voice by itself. And the speaker can wander about the room and talk at the same time without losing a syllable. Eh?
stunna

Sep 30, 2006 at 4:21 PM

I'd like to see how performance is given up when using user mode drivers compared to kernel in gaming, and in general usage.
staceyw Before C# there was darkness...

Oct 01, 2006 at 5:33 PM

Great. Thanks Nar and Charles. I heard the CancelSyncIO call, is there a CancelAsyncIO api also?
Charles Welcome Change

Oct 01, 2006 at 11:19 PM

I like the idea of a wireless mic. Good thinking.
C
Lon^

Oct 02, 2006 at 8:19 AM

Staceyw,

You can already cancel Async IO using the CancelIO function:
CancelIO

The only problem in WinXP is that this only cancels I/O on the current thread although I think you could probably cancel all I/O by storing thread handles from createthread and queueing APCs to them. As long as you had alertable waits this should work.

I think Vista is going to improve on this by implementing a CancelIOEx which should cancel I/O on all threads without the extra work:
CancelIOEx
Cornelius Ellsonpeter

Oct 02, 2006 at 9:16 AM

Charles wrote:

I like the idea of a wireless mic. Good thinking.
C

Great video, Charles. The sound quality is so remarkable...crisp, clear...and I didn't hear a "bzzzzzpt" at the end of this video.
sparky

Oct 02, 2006 at 10:30 AM

This brings up one of the things I have always wondered about win32. Why on earth can't you do an overlapped CreateFile? It doesn't sound like this is going to be changing in Vista either. I've *wanted* to use overlapped IO on many occasions, but I've always been very turned off by this omission. Also, why is it that some overlapped IO calls block for hundreds of milliseconds? Shouldn't asynchronous really mean asynchronous?

I also have one question about user-mode drivers. You talked a little about how we don't want user-mode drivers to host a GUI, etc. But I wasn't sure if you mean that it is impossible for them to do that. Do user-mode drivers run in win32, or are they in a separate subsystem?

OK, one more question and I'm done. In general you can only cancel an operation that is sufficiently started, and not sufficiently finished. Those two restrictions lead directly to the two main classes of bugs associated with "cancel" type API calls. Namely, that you can't be sure you aren't trying to cancel it too early, and that you can't be sure you aren't trying to cancel it too late. The case of trying to cancel it too early can be handled carefully by the application with retries and synchronization, to avoid turning it into a problem. But I can't see how you can, in general, solve the second class of problem, trying to cancel an operation that has just finished, and accidentally cancelling a different operation. Is this something that you have looked into?
Nar Ganapathy

Oct 02, 2006 at 10:56 AM

Yes. In Vista you can use CancelIoEx to cancel asynchronous I/O requests. You can also use the older Win32 API called CancelIo. cancelIo has some restrictions that CancelIEx addresses.

Narayanan

Nar Ganapathy

Oct 02, 2006 at 11:17 AM

Great set of questions. I will try to answer them one by one.

This brings up one of the things I have always wondered about win32. Why on earth can't you do an overlapped CreateFile? It doesn't sound like this is going to be changing in Vista either.

There are many reasons CreateFile is synchronous. Here is one. All Windows APIs are based on object handles. Windows OS has an underlying object manager which parses names and creates objects. These objects have Create<OBJ> apis that return a handle. For example, CreateEvent takes an event name, finds the object and returns a handle to that object. CreateFile parses the file name, creates a file object and returns a handle to it. Other APIs then operate on the handles. These APIs (read/write/ioctl) assume that the Create API has done name parsing, security access control etc. This makes the APIs that operate on the handles fast and efficient. If CreateFile was made asynchronous, we would now have to update all the other APIs that take a file handle and synchronize that with CreateFile processing. This will complicate and hurt the performance of handle based APIs like ReadFile and WriteFile. After all, program calls Read/Write much more often than Create.

I've *wanted* to use overlapped IO on many occasions, but I've always been very turned off by this omission. Also, why is it that some overlapped IO calls block for hundreds of milliseconds? Shouldn't asynchronous really mean asynchronous?

I agree. When an I/O goes into a driver, the driver can immediately queue the request and return. But if there is a deep driver stack, there is a lot of computation that happens, the code waits for locks etc. These slow things down even if you do asynch I/O.

I also have one question about user-mode drivers. You talked a little about how we don't want user-mode drivers to host a GUI, etc. But I wasn't sure if you mean that it is impossible for them to do that. Do user-mode drivers run in win32, or are they in a separate subsystem?

On Vista, User mode drivers run in a win32 process. They run in the context of session 0. So we don't want them throwing UI etc. For one thing they won't be in the right context.

OK, one more question and I'm done. In general you can only cancel an operation that is sufficiently started, and not sufficiently finished. Those two restrictions lead directly to the two main classes of bugs associated with "cancel" type API calls. Namely, that you can't be sure you aren't trying to cancel it too early, and that you can't be sure you aren't trying to cancel it too late. The case of trying to cancel it too early can be handled carefully by the application with retries and synchronization, to avoid turning it into a problem. But I can't see how you can, in general, solve the second class of problem, trying to cancel an operation that has just finished, and accidentally cancelling a different operation. Is this something that you have looked into?

Both these issues can be handled with sufficient synchronization (albeit tricky). In the driver space, if someone cancels an I/O that's already completed, the cancelation is just ignored. If an application wants to make sure that its canceling only the I/O it really wants to cancel, it has to track its overlapped I/O blocks and use the correct synchronization. I agree that providing libraries to help with this task would be useful.

nrohit

Oct 02, 2006 at 11:53 AM

Hakime,

With all due respect, if you are talking about linux/BSD or Mac OSX, they are light years behind Vista.

Linux is still a monolithic kernel, and it will take forever to re-architect the services of the kernel as threads (also called the Mach kernel).

Vista goes one step beyond, they multi-thread each service.

You have to watch the other video about how they re-wrote their networking stack.

Pretty cool stuff really.
nrohit

Oct 02, 2006 at 11:55 AM

Nar,

This was amaaaazing. I really liked the video.
I can see how this kernel will *scale* in the next few years.

Good stuff, my man.

-Rohit
staceyw Before C# there was darkness...

Oct 02, 2006 at 12:51 PM

Nar Ganapathy wrote:

Yes. In Vista you can use CancelIoEx to cancel asynchronous I/O requests. You can also use the older Win32 API called CancelIo. cancelIo has some restrictions that CancelIEx addresses.

Narayanan

Thanks, I was thinking from a managed perspective and cancelling a pending IAsyncResult. I guess they just need to add that to the Framework in 3.5 time.
aJanuary

Oct 06, 2006 at 1:39 PM

" From the video: "Vista the most advanced general purpose OS"!? I really don't think so, please look at the market!!!!!"

In terms of the range of hardware support, I think it probably is.
Charles Welcome Change

Oct 06, 2006 at 6:25 PM

aJanuary wrote:

" From the video: "Vista the most advanced general purpose OS"!? I really don't think so, please look at the market!!!!!"

In terms of the range of hardware support, I think it probably is.

As you will continue to see, from an OS point of view (including hw support obviously) Vista really is the most advanced general purpose OS in the world. I'm not just saying this. Stay tuned for more videos here that will demonstrate exactly why I can make such a claim.

Of course, Vista is a snapshot of the latest and greatest OS technologies from MS designed for general computing on a vast array of hardware. Windows will continue to evolve and in many incredibly interesting and powerful ways.

C
ArthurChao

Oct 06, 2006 at 11:24 PM

I'm from China,and the speed of this site here is a bit slow.
I don't know how to do to have my own page in this site.
Can I have the right to create a page here?
Tell my how to do? Thanks.
nrv

Oct 15, 2006 at 11:05 PM

Very good overview of the windows vista IO. Thanks for sharing the details! I also feel that moving many of the device classes for those devices to usermode is a good thing. Given the initial Mach base of Windows NT, this should be a natural path for Windows!
dialtr

Feb 10, 2007 at 11:15 AM

Someone on this thread mentioned that NT was based on Mach. Just thought I'd point out that this is not true. Mach was a research project at Carnegie Mellon, and while it is true that Richard Rashid was hired by Microsoft at one point, he was not involved really in the development of NT aside from some minor research related to paging the kernel.

The Windows NT kernel was designed from scratch by Dave Cutler and his team at Microsoft, most of whom came from Digital Equipment Corp and were involved with the development of VMS (another Cutler design.)

This is a long held misconception, perhaps related to the fact that both operating system kernels (Mach and NT) were billed as microkernels, when in fact both kernels are better classified as "hybrid kernels."

But aside from being modern operating systems, they are not related.

References:
"Showstopper!" by G. Pascal Zachary
"Inside Windows NT" David Solomon
Rich Rich Ersek

Nov 15, 2007 at 12:32 AM

Digital's research group built a pilot of VMS running on Mach but never took it to production. Having been written in the proprietary BLISS language, it would have been far too difficult to make the port.

-Rich