Version number in one place is impossible?

NTDEV
1

List,

I am trying to invoke stampinf and reuse the version information from a header file in the project. The fewer places to maintain the version number the better, right?

Therefore, I want to create the STAMPINF_VERSION environment variable before I execute the stampinf utility. As you know, the variable is an alternative to specifying a version using -v on the command line.

I have set up a “post build step” by specifying NTTARGETFILE2=post_build_sign in my SOURCES file. The implementation has so far been varied but unsuccessful.

1-- From inside the post build step I tried to generate an include file that would be included and set the variable. Thanks to Mr. Cattley for the idea in this thread: http://www.osronline.com/showThread.cfm?link=151398

If I use only one block in makefile.inc I seem unable to mix !commands with commands that should be executed (copy, stampinf, etc). So I had to use two blocks, where my post_build_sign became dependent on another block that would generate and include the new include file. The problem is the second block seems to have its own variable scope because the variable is created successfully, but when returning to post_build_sign it no longer exists.

2-- I discovered a command that works well when used from a regular command prompt, and reads the variable value from a file, but completely fails when used in makefile.inc

C:\>set /P STAMPINF_VERSION=dummy < file

When used in makefile.inc the variable “/P STAMPINF_VERSION” is created with a value of “dummy < file”. How useful…

3-- Generate a batch file instead and call it right before i invoke stampinf. This has the same problem as #1 in that the variable is created but once execution returns from the call, the variable is wiped.

4-- Generate a batch file that also runs stampinf after it creates the variable. This should work but I am experiencing some weirdness :slight_smile:

From makefile.inc

copy “$(OBJ_PATH)\stampinf.template” “$(OBJ_PATH)$(O)\stampinf.template” /y >nul
copy “$(OBJ_PATH)$(O)\stampinf.bat” + “$(OBJ_PATH)$(O)\stampinf.template” /y >nul

The appended file is then created as “$(OBJ_PATH)\stampinf.bat” with an extra 0x1A character at the end. How is this possible?

I probably tried more things but those are the ones I can think of. Please let me know if you have had better success at solving the same problem.

Best regards,

Otto

2

The 0x1A character is control-z, used as end of file marker in MS world.
It should not be a problem, most Windows programs handle it well.
If you really want to get rid of it, use /B switch with copy command.

– pa

3

This is a DIY area of drivers that different people do it differently. I set my version in sources and make it available to stampinf, the version resource, and the code. I like it in sources rather than a parameter since it gets automatically frozen in source control for releases and changing the version automatically sets a dependency to rebuild everything.

4

I set the version outside of build - I run build from a ‘normal’
makefile and can do obvious normal makefile like things right there,
including generating any version information.

Mark Roddy

On Thu, Nov 4, 2010 at 8:57 PM, wrote:
> This is a DIY area of drivers that different people do it differently. I set my version in sources and make it available to stampinf, the version resource, and the code. I like it in sources rather than a parameter since it gets automatically frozen in source control for releases and changing the version automatically sets a dependency to rebuild everything.
>
>
> —
> 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
>

5

Thanks guys.

I’m interested in Bob’s approach. You say the version information is set in SOURCES, but also available to the code, so it can be returned from an IOCTRL?

I did manage to get it working in the end. It’s not the most beautiful solution but this is for legacy code, for which I’m creating a new build system. So rather this hack than change the code too much.

==SOURCES==BEGIN==



NTTARGETFILE2=post_build_sign

==SOURCES==END==

==Makefile.inc==BEGIN==

generate_stampinf : “$(OBJ_PATH)$(O)$(TARGETNAME).sys”
!if [def2env -nq -ccd -hf “$(OBJ_PATH)..\Include\randomheader.h” -hv VER_PRODUCTVERSION -bf “$(OBJ_PATH)$(O)\stampinf.bat” -bv STAMPINF_VERSION]
!endif

post_build_sign : generate_stampinf
set WDK_TARGET_FOLDER=$(OBJ_PATH)$(O)
set WDK_TARGET_NAME=$(TARGETNAME)
copy /Y /B “$(OBJ_PATH)$(O)\stampinf.bat” + “$(OBJ_PATH)\stampinf.template” “$(OBJ_PATH)$(O)\stampinf.bat”
copy /Y /B “$(OBJ_PATH)$(TARGETNAME).inx” “$(OBJ_PATH)$(O)$(TARGETNAME).inf”
signtool sign /v /ac “$(OBJ_PATH)..\MSCV-GlobalSign.cer” /n “Acme Ltd” /t http://timestamp.verisign.com/scripts/timestamp.dll “$(OBJ_PATH)$(O)$(TARGETNAME).sys”
call “$(OBJ_PATH)$(O)\stampinf.bat”
inf2cat.exe /driver:“$(OBJ_PATH)$(O)” /verbose /os:vista_x86,vista_x64,server2008_x86,server2008_x64
signtool sign /v /ac “$(OBJ_PATH)..\MSCV-GlobalSign.cer” /n “Acme Ltd” /t http://timestamp.verisign.com/scripts/timestamp.dll “$(OBJ_PATH)$(O)$(TARGETNAME).cat”

==Makefile.inc==END==

==stampinf.template==BEGIN==

stampinf -f “%WDK_TARGET_FOLDER%%WDK_TARGET_NAME%.inf” -d *

==stampinf.template==END==

You will notice a reference to the def2env tool which I also had to create, for extracting a #defined variable and normalizing it according to some rules, and generating a batch file.

Bob, perhaps you can show us the proper way to do things? :wink:

Otto

6

> I am trying to invoke stampinf

stampinf has a nasty bug of always using local date/time, not the UTC one. This makes it incompatible with inf2cat (which assumes the INF date to be UTC) in some scenarios - some timezones in some day hours.

I personally solved this by manually generating “makeinf.bat” using > and >> operators from the MAKEFILE.INC (it also uses “svnversion” to set the driver version), and then invoking this .bat.

Here is how the generated makeinf.bat looks like:

set STAMPINF_DATE=11/05/2010
stampinf -f %1 -v 2.2.57.7451

the last 4 digits of the version stamp is “svnversion” output, and the date is generated by the special .vbs script also invoked from MAKEFILE.INC

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

7

> I’m interested in Bob’s approach. You say the version information is set in SOURCES

I have VERSION.INC which keeps the version numbers. It is !included to SOURCES.

Then the pre-build step in SOURCES invokes “svnversion” and cats the SVN’s version to the 3 digits from VERSION.INC, thus making a “svnver.h” tmp header file.

This header is #included to .rc to provide the binary’s version info, and also to the code.

Also, SOURCES generates MAKEINF.BAT using the same numbers + the current UTC time from the .vbs script. Then MAKEINF.BAT is invoked, calling “stampinf” and thus generating .inf from .inx.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

8

Thank you Maxim. This is extremely helpful.

What is the content of your VERSION.INC? Is it only the version data or a statement to set some variable? Can you show a couple of lines from SOURCES how the version info is included and processed?

Also, thank you for the heads up on stampinf/inf2cat.

Otto

9

+1

A lot to be said for running build from a makefile, I think.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, November 04, 2010 9:45 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Version number in one place is impossible?

I set the version outside of build - I run build from a ‘normal’
makefile and can do obvious normal makefile like things right there,
including generating any version information.

Mark Roddy

On Thu, Nov 4, 2010 at 8:57 PM, wrote:
> This is a DIY area of drivers that different people do it differently. I
set my version in sources and make it available to stampinf, the version
resource, and the code. I like it in sources rather than a parameter since
it gets automatically frozen in source control for releases and changing the
version automatically sets a dependency to rebuild everything.
>
>
> —
> 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
>

—
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

10

> What is the content of your VERSION.INC? Is it only the version data or a statement to set some

variable?

Statement to set a variable.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

11

Maxim S. Shatskih wrote:

> What is the content of your VERSION.INC? Is it only the version data or a statement to set some
> variable?
Statement to set a variable.

I have this in an include file that is version controlled:
#define VER_BUILD 20
Then my resource file does:
FILEVERSION 1,0,1,VER_BUILD
and a pair of macro builds the string version.
#define STRINGER(w, x, y, z) #w “.” #x “.” #y “.” #z
#define XSTRINGER(w, x, y, z) STRINGER(w, x, y, z)
Value “FileVersion”, XSTRINGER(1,1,VER_BUILD)

The nice thing about that is I can pull the number in a batch file for
stampinf and for building my zips:
for /f “tokens=3” %%i in (verbuild.h) do set BLD=%%i
stampinf -f %1 -d * -v 1.0.1.%BLD%

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.