Design choices

NTDEV
1

Dear,

I’ve spent the last 2 weeks testing some functionnalities of the WDF and now I’d like to start again from scratch my driver because it seems that the design choices I made are not good at all. I’m a total beginner, and I’d like you to advice me the best design for the following prerequists, as well as pointing the resources that would help me starting such a project.

The hardware :

  • The hardware I’m working on exposes multiple HID interfaces : keyboard, mouse, joystick, custom HID raw interface (sending all the raw data from the sensors), and an in/out command interface.
  • When plugging the device in Windows I end up with multiple things in the properties of my device : a USB Composite Device, 5 USB input device, 1 HID keyboard, 1 hid mouse, 1 hid game controller, and 2 hid compliant devices.

The device has to work without a driver. It has basic functionnalities that works on any OS using the HID interfaces.

My aim is to extend these functionnalities with mapping capabilities : I’d like from the raw data and a user configured mapping table to be able to answer mouse/keyboard/joystick read requests.

Doron who answered most of my posts advices me to look into developping a custom hid miniport. This sounds good but I’ve got some troubles figuring out a few things, and understanding the mechanics behind the miniport :

  • What’s the job of a miniport ?
  • Is it the miniport that will expose itself these interfaces ? do I need to “uninstall” the basic HID ones when installing the miniport ?
  • Is there any sample (WDF if possible) I could use to start ?
  • Is it something, as a begginer, I could possibly do in 30 working days time ?

It would be very helpfull if you could answer one or more of my questions, give me advices or just a starting point for my research.

Best regards,

2

I know little about HID devices. I know something about driver writing, however, so I’ll comment on this:

[quote]
Is it something, as a begginer, I could possibly do in 30 working days time ?

[quote]

As somebody who’s been writing Windows drivers since, well, forever it is hard for ME to imagine committing to write a driver – even a KMDF driver – from starting design to “ready to release to production” in “30 working days time.” As a general rule of thumb, I would ordinarily consider 6 weeks elapsed time enough to get a simple driver to beta or a complicated driver to alpha.

But then there’s testing and bug fixing.

The problem is adding-in the amount of time you need for learning. And testing. And re-learning. And testing again. And re-writing. And learning.

I don’t mean to discourage you, but if you really want to go from design to shipping in 6 weeks, I think that’s quite a challenge… for anyone.

Peter
OSR

3

I see your point. So my question now is to know if this is a “simple” project. Being in beta in 6 weeks is definitely acceptable. I’m crushed by time but I prefer showing something right even not finished than showing a finished badly designed project.

If anyone could help proposing the best design and understanding the miniport thing, I’d be very pleased.

Thanks again to all of you for your help.

4

I think Peter’s answer didn’t quite make it across. Writing kernel
drivers is hard and takes a long time for experienced folks. It isn’t
anything like user mode code. Something breaks and your whole machine
is shot because you killed the OS. Reproducing it is difficult and
then even figuring out what the problem is can take days. I worked on
a single issue with NavAP once that took 2-3 months to track down and
it turned out it wasn’t a bug at all but disk corruption. You are
proposing really many drivers, not just one. Since your starting
point is ‘What is a miniport?’, I would suggest you quote 2 months
just to provide an estimate and 6 months highly variable for the whole
thing. As Peter, I’m not trying to discourage but rather put you on
good footing where you have a reasonable chance.

On 1/28/11, xxxxx@gmail.com wrote:
> I see your point. So my question now is to know if this is a “simple”
> project. Being in beta in 6 weeks is definitely acceptable. I’m crushed by
> time but I prefer showing something right even not finished than showing a
> finished badly designed project.
>
> If anyone could help proposing the best design and understanding the
> miniport thing, I’d be very pleased.
>
> Thanks again to all of you for your help.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Sent from my mobile device

5

I will go even further than David, most experienced professional
developers would not consider undertaking a driver project in six weeks
unless it was extremely trivial.

A well conceived project will need a design which unless you have
already done something very close cannot be whipped off and approved in
less than several weeks. You have development and debugging time which
will be significant. You have the fun of learning about code signing
for 64-bit, again this can take a day or two on its own to get it right.

Since your driver is in known category it is good practice to use DTM,
which can easily take a week or more the first time you try. What other
test code do you have to exercise the driver and its devices, writing
good test code in some cases takes longer than writing the driver
itself.

Along with testing are you going to take the time for designing good
diagnostics in the driver? This will add to the development time, but
can significantly reduce support time for things like the beta and once
the product is shipping.

This does not even count do you have the hardware resources for doing
the project? Most people get surprised to discover you need a separate
machine (or virtual machine in some cases) to debug the driver. For DTM
you are going to need a minimum of 3 computers.

You will not get this done in six weeks, in fact depending on the number
of drivers and their complexity, David’s proposal of 8 months is highly
aggressive. As Peter and David have stated, this is not to discourage
you, but to allow you to understand the complexity of the project and to
try to give you the tools to explain it to your managers.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“David Luxford” wrote in message news:xxxxx@ntdev:

> I think Peter’s answer didn’t quite make it across. Writing kernel
> drivers is hard and takes a long time for experienced folks. It isn’t
> anything like user mode code. Something breaks and your whole machine
> is shot because you killed the OS. Reproducing it is difficult and
> then even figuring out what the problem is can take days. I worked on
> a single issue with NavAP once that took 2-3 months to track down and
> it turned out it wasn’t a bug at all but disk corruption. You are
> proposing really many drivers, not just one. Since your starting
> point is ‘What is a miniport?’, I would suggest you quote 2 months
> just to provide an estimate and 6 months highly variable for the whole
> thing. As Peter, I’m not trying to discourage but rather put you on
> good footing where you have a reasonable chance.
>
> On 1/28/11, xxxxx@gmail.com wrote:
> > I see your point. So my question now is to know if this is a “simple”
> > project. Being in beta in 6 weeks is definitely acceptable. I’m crushed by
> > time but I prefer showing something right even not finished than showing a
> > finished badly designed project.
> >
> > If anyone could help proposing the best design and understanding the
> > miniport thing, I’d be very pleased.
> >
> > Thanks again to all of you for your help.
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> –
> Sent from my mobile device

6

Dear,

I’d like to thank you all for you answers. I understand that producing such a driver might be longer than I thought, and I’ll take good note of your remarks.

However, no matter how long it could take, I’d be pleased if I could understand with your help a possible design for my problematic, in order to give correct explanations to my client.

Best regards,