Peter W. Morreale wrote:
The documentation for the DriverVer directive of the Version section
states:
“This value specifies the date of the “driver package”, which includes
the driver files and the INF. This date must be the most recent date of
any file in the driver package.”
This is really only used during installation, when the system chooses
between your new package and any existing packages. “New” packages (as
defined by DriverVer) are preferred. If you are not doing update-type
installations, this won’t really matter.
Does this really mean that I need to change the in[xf] file every day
during development?
I certainly do. The “StampInf” tool in the DDK was built for exactly
this purpose. It substitutes date and version number into substitution
strings in the INF file. The samples have a “template” INF file with an
“inx” extension, then use a “makefile.inc” makefile extension to run
stampinf to produce the INF from that. I use a similar technique in my
builds.
However, I don’t copy in the INF file for every test. I often just copy
the driver binary directly to system32\drivers and restart the driver.
I always do an uninstall/reinstall before shipping them to clients, however.
Also, Even through I specify a DriverVer of:
DriverVer = 12/18/2009,1.0.0.0
Device Manager always reports my driver version as:
Driver Version: 6.1.7600.16385
which appears to be the release of the WDK. (The “Driver Date” is
always the date of the build) Why is my version being ignored?
The displayed “Driver Version” comes from the version resource in the
driver. Unless you are updating the version resource yourself, you’re
getting standard numbers built-in to the WDK. I have scripts that run
as part of my build process that embed a version number, and scripts
that “bump” it to the next number automatically.
The “DriverVer” string is contained in the registry, but I’m not sure
anyone displays it externally.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
