Hello,
I know I can use GetFileVersionInfo() API to retrieve ANY file version number programmatically from the user mode application. That how a user mode application can use GetFileVersionInfo() to retrieve its own version number.
But how can I do the same for a driver, if I want to inplement an IOCTL for query of driver version number?
Thanks & best regards,
WH Tan
Your inf has enrolled your driver in the system. You can get any information about this driver in use mode. So why do u let driver tell the version? Query system by yourself.
> But how can I [get the file version] for a driver, if I want to
inplement an IOCTL for query of driver version number?
Compile the version number into the driver itself (during the build) and
have this reported by a IOCTL call.
You want to report back the version of the actually loaded and used
binary driver, not some information from a resource info block.
One of the best ways to do this and keep the versions in the resources,
driver, and inf is to define it in a header file and use that header in all
locations. You will need a text utility to put that info into the inf
files, but it is easy to have both the source code and resource file use a
standard header file.
“Hagen Patzke” wrote in message news:xxxxx@ntdev…
>> But how can I [get the file version] for a driver, if I want to
>> inplement an IOCTL for query of driver version number?
>
>
> Compile the version number into the driver itself (during the build) and
> have this reported by a IOCTL call.
>
> You want to report back the version of the actually loaded and used
> binary driver, not some information from a resource info block.
>
From: “David Craig”
> One of the best ways to do this and keep the versions in the resources,
> driver, and inf is to define it in a header file and use that header in
> all locations. You will need a text utility to put that info into the inf
> files, but it is easy to have both the source code and resource file use a
> standard header file.
To embelish, you can direct that text utility to your sources or
makefile.inc file to parameterize a call to StampInf. KMDF drivers are
presumably already using StampInf and the .INX file scheme used in the WDK
samples, so this might not be a big change in procedure for a lot of people.
Hmm. Now that I think about it, defining some compile-time macros in the
SOURCES file is a simple way to deal with the whole problem. The driver uses
the macro values to tell it what version it is, and StampInf puts the same
version number into the INF file. This puts the version number in a single
place. You just need the discipline to change it each time you should.
Walter Oney
Consulting and Training
www.oneysoft.com
Or use a Major.Minor.Version.Build number scheme where you manually
change Major.Minor.Version as needed but automatically change Build
every time you build the product. I hate duplicate version numbers.
“What version is installed?, Oh, yes, but what is the date of that version?”
Mark Roddy
On Thu, Apr 9, 2009 at 12:42 PM, Walter Oney wrote:
> From: “David Craig”
>>
>> One of the best ways to do this and keep the versions in the resources,
>> driver, and inf is to define it in a header file and use that header in all
>> locations. ?You will need a text utility to put that info into the inf
>> files, but it is easy to have both the source code and resource file use a
>> standard header file.
>
> To embelish, you can direct that text utility to your sources or
> makefile.inc file to parameterize a call to StampInf. KMDF drivers are
> presumably already using StampInf and the .INX file scheme used in the WDK
> samples, so this might not be a big change in procedure for a lot of people.
>
> Hmm. Now that I think about it, defining some compile-time macros in the
> SOURCES file is a simple way to deal with the whole problem. The driver uses
> the macro values to tell it what version it is, and StampInf puts the same
> version number into the INF file. This puts the version number in a single
> place. You just need the discipline to change it each time you should.
>
> Walter Oney
> Consulting and Training
> www.oneysoft.com
>
> —
> 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
>
On 2009/4/9 Hagen Patzke wrote:
> But how can I [get the file version] for a driver, if I want to
> inplement an IOCTL for query of driver version number?Compile the version number into the driver itself (during the build) and
have this reported by a IOCTL call.You want to report back the version of the actually loaded and used
binary driver, not some information from a resource info block.
Confused. I mean I was confused.
Thanks for pointing it out.
That’s actually my intention - to have the driver reports back its own
version number. I always aware of the risk and mis concept when
working with a driver project by applying the method of user mode
application to a kernel mode driver. 
What I was confused is I was actually somewhat reluctant to have this
version info hard coded at several places. i.e.
and finally the all important INF file. Fortunately, the latest WDK
has stampInf utility to handle the INF part, as Walter pointed out, of
which I had been making use of.
Sound like both David and Walter have some idea with regard to this
concern… Let me first try to understand what they have to say.
Thanks again and best regards,
–
WH Tan
whsiung@tm.net.my wrote:
I know I can use GetFileVersionInfo() API to retrieve ANY file version number programmatically from the user mode application. That how a user mode application can use GetFileVersionInfo() to retrieve its own version number.
But how can I do the same for a driver, if I want to inplement an IOCTL for query of driver version number?
I just have the application run GetFileVersionInfo on the driver binary.
I use a variant of what Walter described. I have a file called
“verbuild.h”, which gets included into the .rc file, and processed to
create the “stampinf” call. I then have a script called “bump.bat” that
bumps the number in that file up to the next version. That way, it’s
easy to bump it when I need to.
It’s interesting that my natural tendency is to “conserve” version
numbers, as if they were costing me money. If I were smarter, I’d bump
them at every build, to avoid the conversation Mark described: “yes,
it’s build 64, but which date?”
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
WH Tan wrote:
and finally the all important INF file. Fortunately, the latest WDK
has stampInf utility to handle the INF part, as Walter pointed out, of
which I had been making use of.
Here’s one thing to remember about the INF file. The version number in
the INF file gets copied to the registry at the time the dev node is
created, which means at installation time. If you update the driver
binary, the registry does not get changed. It’s easy to get fooled by this.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Walter Oney
Sent: Thursday, April 09, 2009 6:42 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] How to retrieve driver’s version number?Hmm. Now that I think about it, defining some compile-time
macros in the
SOURCES file is a simple way to deal with the whole problem.
The driver uses
the macro values to tell it what version it is, and StampInf
puts the same
version number into the INF file. This puts the version
number in a single
place. You just need the discipline to change it each time you should.
Even disciplined people make mistakes. It is better to have it automated
i.e. nighty build incrementing build number and setting an environment
variable which can be used in SOURCES for drivers, to set version in the
INF and to create version info script for binaries.
We use X.Y.Z.build_number scheme as Mark pointed out. X, Y and Z are
stored in project definition file and handled manually by project owner
(typically there are only few changed per year) build number is handled
by build engine and can be only incremented. This way every build has
unique number and that’s all we need to know when a customers reports a
problem. X, Y and Z have more or less marketing value.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Slave the ioctl handler and the version resource to the same #define in a common header file.
-----Original Message-----
From: WH Tan
Sent: Thursday, April 09, 2009 11:11
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to retrieve driver’s version number?
On 2009/4/9 Hagen Patzke wrote:
>> But how can I [get the file version] for a driver, if I want to
>> inplement an IOCTL for query of driver version number?
>
>
> Compile the version number into the driver itself (during the build) and
> have this reported by a IOCTL call.
>
> You want to report back the version of the actually loaded and used
> binary driver, not some information from a resource info block.
Confused. I mean I was confused.
Thanks for pointing it out.
That’s actually my intention - to have the driver reports back its own
version number. I always aware of the risk and mis concept when
working with a driver project by applying the method of user mode
application to a kernel mode driver.
What I was confused is I was actually somewhat reluctant to have this
version info hard coded at several places. i.e.
- the handler of version querying IOCTL,
- the driver resource file, where the user will see this info via file
properties in windows explorer, or driver properties in device
manager,
and finally the all important INF file. Fortunately, the latest WDK
has stampInf utility to handle the INF part, as Walter pointed out, of
which I had been making use of.
Sound like both David and Walter have some idea with regard to this
concern… Let me first try to understand what they have to say.
Thanks again and best regards,
–
WH Tan
—
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
If you update the driver, for example through the Device Manager, will a
newer version number from the INF get propagated to the registry?
Cheers,
–mkj
Tim Roberts wrote:
WH Tan wrote:
> and finally the all important INF file. Fortunately, the latest WDK
> has stampInf utility to handle the INF part, as Walter pointed out, of
> which I had been making use of.
>Here’s one thing to remember about the INF file. The version number in
the INF file gets copied to the registry at the time the dev node is
created, which means at installation time. If you update the driver
binary, the registry does not get changed. It’s easy to get fooled by this.
–
//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________
Hi folks,
Thanks very much to all of you for your suggestions.
I was short of idea and I think I have got plenty now
Best regards,
WH Tan
Hi,
Thanks very much once again to all of you, especially Walter and Tim. I have got it.
I have this in my SOURCES file and it’s really nice to have the version info maintained in a single place.
…
VERSION_MAJOR=1
VERSION_MINOR=10
VERSION_REVISION=1
VERSION_BUILD=500
…
C_DEFINES = -DMY_VERSION_MAJOR=$(VERSION_MAJOR) \
-DMY_VERSION_MINOR=$(VERSION_MINOR) \
-DMY_VERSION_REVISION=$(VERSION_REVISION) \
-DMY_VERSION_BUILD=$(VERSION_BUILD) \
$(C_DEFINES)
Now the solution to the original question is simplified… as oppose to my origianl question, where it’s actually oversimplified
Best regards,
WH Tan
On 4/9/2009 8:49 PM, Tim Roberts wrote:
It’s interesting that my natural tendency is to “conserve” version
numbers, as if they were costing me money. […]
Instead of a build number, we use version numbers from our RCS.
Subversion (SVN) assigns a single number to one checked-in “state” of a
whole repository, which can be queried by invoking “svnversion” on the
root of the tree you are interested in.
ALL source tree changes reflect in this “svnversion” number, not just a
change of the current file.
Note that as long as you have modifications and partial merges,
svnversion reports not a single number but a range like “14000:14005M”.
(Yes, if you use the output directly as a numeric constant, this might
break a release build. Very useful to prevent releases from un-committed
source. )