doronh

your welcome. glad everyone liked the work we have done so far

hopefully we can do a screencast of the state machines to compensate for the low res shots in this video .  need to work out all the IP issues before we do that though.

d

as for mini-drivers, i assume you mean drivers that fit into a port/miniport model like NDIS or SCSIPORT.  Those stay the same for now, but you won't likely see new port driver models that are not KMDF based.  KMDF fits into some existing models today as well.  For instance you can easily write an NDIS-WDM driver using KMDF to do all the WDM aspects.

d

pierre: I guess charles could have used a synonym for complicated, but in the end, writing a driver is complicated.  Unlike a user mode application where preemption doesn't happen that often on a UP machine, a driver can easily get preempted on the same thread.  You have to think about synchronization all the time in every context...it's a tough thing to do...and the consequences are harsh .

Yes, it sounds crazy that 1000s of lines of code go away, but they do.  WDM had a ton of state changes which implied many similar actions.  KMDF formalized it and broke it down into actions w/only one purpose.  this makes the code much more compact.

massif:  i have not heard good things about windriver, so i am glad we can meet a need in that space.  Debugability is important to our team.  The debugger team is a separate team from us (in a different org as well), so getting huge changes into the debugger is a bit hard.  We took the route of making a very extensive debugger extension (Wdfkd.dll) to make debugging easier.

Gandalf:  yeah, the naming thing is totally geek .  You only appreciate once you have been bitten by inconsistent naming in the past.  I'm glad someone else appreciates it.  Hopefully we can do the screencast soon, right now getting vista out the door takes up alot of my time