Re: Driver "update" during development cycle and WHQL certification

First you should consider moving to a supported driver development
environment, the W2k3 DDK is 4 to 5 revisions out of date, get the Windows 7
WDK which builds drivers just fine back to Windows XP. Second is your
driver plug and play, if so you should be able to disable the driver, then
load the new one and have it loaded (or better yet using Windbg have the
debugger load the current version every time the driver starts). If your
driver is not plug and play you will have problems moving to anything beyond
XP. If your driver is not plug and play, consider rewriting it in KMDF to
make if PnP.

No system will refuse to load a non-WHQL driver, 64-bit systems will refuse
to load a driver with a digital signing but this is not WHQL. Even then,
there is a boot time option to override this behavior for a given boot. so
for debugging just choose the option while you are debugging. You will have
a problem when you decide to release the driver for 64-bit because you need
a digital signature and that requires a company, rather than go into the
details go to http://www.osronline.com and join NTDEV there was a recent
discussion titles "Question of about globalsign and verisign"


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





"David G" <> wrote in message
news:e63a5d18-741e-41f2-bbbe-...
> Two questions in one.
>
> First of all, I'm what's known in the game arena as an "indie"
> developer. As in I'm doing this at home on my own time, mostly as a
> learning exercise. I've downloaded the W2K3 DDK, since my desktop
> system is XP, therefore it makes the most sense to develop for XP.
>
> My environment is that I have one of these:
> http://www.x10.com/products/x10_cm19a.htm
> and the drivers available for it have no documentation at all.
> Therefore it's impossible to write 3rd party software that can talk to
> it. I've taken the Linux driver source as a reference point, and have
> got to the stage that I can open the device, and the two pipes on it.
>
> The big problem I face is the development cycle time. Every time I
> rebuild the driver, it appears I have to reboot to get it recognized.
> Even though I can overwrite the old one in \windows\system32\drivers,
> changes don't take effect till I reboot. Is there a faster way to do
> this, some way to tell windows to stop using the old driver and start
> using the new?
>
> If and when I update this for Vista and/or W7, WHQL is going to get to
> be an issue. So that also raises two more questions.
>
> Firstly, on a system that refuses to load a non WHQL driver, how do
> you break the chicken and egg problem? Meaning how do you build and
> test the driver in the first place so you have something that can be
> WHQL tested?
>
> Secondly, once you do have a driver candidate, is it even possible for
> an individual working on a driver, evenings and weekends, to get
> Miscrosoft to certify something, and if so, exactly how would I go
> about doing this?
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4625 (20091120) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4625 (20091120) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com