How to share source code when we develop Windows device drivers

Benjamin_Kim · August 23, 2010, 10:26pm

TARGETNAME=OneOfMyDrivers
TARGETTYPE=DRIVER
INCLUDES=…\inc;…..\Common\Crypto
TARGETLIBS=$(SDK_LIB_PATH)\wdmsec.lib
SOURCES=OneOfMyDrivers.c \
OneOfMyDrivers.rc\
…..\Common\Crypto\aes_modes.c \
…..\Common\Crypto\aescrypt.c \
…..\Common\Crypto\aeskey.c \
…..\Common\Crypto\aestab.c

Without making a static library(in this case Crypto modules),
Can I build this makefile in this way. I don’t know why it doesn’t work.
I want to share the Crypto module’s source codes with other drivers(and Apps)

Is it possible?
Is the only way a making a static library?

Ken_Johnson · August 23, 2010, 10:29pm

Either make a static library (preferable) or use a source file that #includes the target source file.

S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Monday, August 23, 2010 19:26
To: Windows System Software Devs Interest List
Subject: [ntdev] How to share source code when we develop Windows device drivers

TARGETNAME=OneOfMyDrivers
TARGETTYPE=DRIVER
INCLUDES=…\inc;…..\Common\Crypto
TARGETLIBS=$(SDK_LIB_PATH)\wdmsec.lib
SOURCES=OneOfMyDrivers.c OneOfMyDrivers.rc …..\Common\Crypto\aes_modes.c …..\Common\Crypto\aescrypt.c …..\Common\Crypto\aeskey.c …..\Common\Crypto\aestab.c

Without making a static library(in this case Crypto modules),
Can I build this makefile in this way. I don’t know why it doesn’t work.
I want to share the Crypto module’s source codes with other drivers(and Apps)

Is it possible?
Is the only way a making a static library?

—
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

Benjamin_Kim · August 23, 2010, 10:33pm

> Use a source file that #includes the target source file.

I can’t understand this sentence.
Give me a little detail or an example please.

mm1 · August 23, 2010, 10:36pm

I think that Ken means something like:

Source1.c:

Source2.c:
#include “source1.c”

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, August 23, 2010 10:36 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to share source code when we develop Windows device
drivers

> Use a source file that #includes the target source file.

I can’t understand this sentence.
Give me a little detail or an example please.

—
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

Gary_Little-3 · August 23, 2010, 11:10pm

Now, if you think that is fugly, good, because your better choice is the lib
file. The problem, as I recall, having attempted the same thing, is that
while the build process takes “…\file.x”, it won’t take “…..\file.x”.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Monday, August 23, 2010 9:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to share source code when we develop Windows device
drivers

I think that Ken means something like:

Source1.c:

Source2.c:
#include “source1.c”

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, August 23, 2010 10:36 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to share source code when we develop Windows device
drivers

> Use a source file that #includes the target source file.

I can’t understand this sentence.
Give me a little detail or an example please.

—
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

mm1 · August 23, 2010, 11:19pm

You also have some more options, all of them to varying degrees bad:

a.) You could create symlinks. This assumes that you’re file system
supports them (practically speaking, NTFS on Vista+), that your source
control system doesn’t create problems with them and that you don’t ever try
to build this on a system that doesn’t support symlinks.

b.) You could do the same, but with hardlinks. Source control systems
frequently break these, with the result being two separate files when you
check them out. Also, archiving might do this as well.

c.) As a variation on a or b, you could create a build step that creates
the links before building and deletes them when done so that they do not get
scc’d.

In the end, you are probably better off building a library, ugly though it
can be in some cases.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, August 23, 2010 11:10 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to share source code when we develop Windows device
drivers

Now, if you think that is fugly, good, because your better choice is the lib
file. The problem, as I recall, having attempted the same thing, is that
while the build process takes “…\file.x”, it won’t take “…..\file.x”.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Monday, August 23, 2010 9:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to share source code when we develop Windows device
drivers

I think that Ken means something like:

Source1.c:

Source2.c:
#include “source1.c”

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, August 23, 2010 10:36 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to share source code when we develop Windows device
drivers

> Use a source file that #includes the target source file.

I can’t understand this sentence.
Give me a little detail or an example please.

—
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

—
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

Benjamin_Kim · August 24, 2010, 12:11am

@Gary Little

Now, if you think that is fugly, good, because your better choice is the lib
file.

Yes! How did you know that?
Of course, I’m appreciating them for teaching me the tips.

Benjamin_Kim · August 24, 2010, 12:14am

@mm

You could create symlinks.
I’m using Win7. And my project partners are too.
We are using subversion.
But I concern we get someone new member who use winXP.

So, I have decided to make a static library. It’s the most clean way, isn’t it?

Thanks all.

mm1 · August 24, 2010, 12:22am

It’s the safest way certainly.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, August 24, 2010 12:16 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to share source code when we develop Windows device
drivers

@mm

You could create symlinks.
I’m using Win7. And my project partners are too.
We are using subversion.
But I concern we get someone new member who use winXP.

So, I have decided to make a static library. It’s the most clean way, isn’t
it?

Thanks all.

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

Gregory_G_Dyess · August 24, 2010, 8:39am

Another option is to use your svn to link the file into both places as well with svn externals. It is probably the cleanest approach if the projects are not otherwise linked tightly. If the various projects are actually parts of a larger whole and interdependent, then go the library route.

Using your SCM to “share” the files is by far the cleanest approach and works on all windows platforms that support the scm.

Greg

— xxxxx@gmail.com wrote:

From: xxxxx@gmail.com
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] How to share source code when we develop Windows device drivers
Date: Tue, 24 Aug 2010 00:16:06 -0400 (EDT)

@mm
> You could create symlinks.
I’m using Win7. And my project partners are too.
We are using subversion.
But I concern we get someone new member who use winXP.

So, I have decided to make a static library. It’s the most clean way, isn’t it?

Thanks all.

—
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

Maxim_S_Shatskih · August 24, 2010, 4:24pm

> Without making a static library(in this case Crypto modules),

Better make a static lib.

SOURCES does not support pathnames referencing anything in the directories except the current one and the immediate parent.

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

Maxim_S_Shatskih · August 24, 2010, 4:25pm

> a.) You could create symlinks. This assumes that you’re file system

supports them (practically speaking, NTFS on Vista+),

…and major issues with repeatable buildability.

#include “file.c” seems to be better.

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

OSR_Community_User · August 24, 2010, 8:47pm

No worries m8, there is a clean solution. Instead of using build, just write a simple makefile. All you need to do is copy a few things from the build log like the compiler & linker command lines. Then you have the flexibility to layout your source files any way you want.

There are many other nice benefits to this approach. You can elimate the meaningless diagnostic spew build spits out every time you compile your code that buries warning messages. You can put your output files in a simple and logical arrangement rather than the ridiculous subtree build makes. You can auto sign your driver as a makefile step. Throughout my career I have noted the makefile approach is preferred for driver craftsmen who put pride in every area of their work because it can be tuned to meet any engineering needs perfectly. Build on the other hand is a bit of a joke. Its limiting, hard coded nature is also error prone. For instance, it is unbelievable to me the WDK samples are such that if you change a MOF file and press build that iit does not notice anything changed and does absolutely nothing. Ridiculous.

mm1 · August 24, 2010, 8:54pm

I agree with most of what you said about build, but the major problem with
this approach is that if you do this, you’re going to find it very difficult
to get help on lists like this. I am not necessarily advising against it,
as pretty clearly, bigger problems have been solved than writing a makefile
for a driver project, but I think it is important to mention this potential
problem, depending on what you are looking for.

Whatever you do, however, make sure that you use the WDK toolchain.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, August 24, 2010 8:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to share source code when we develop Windows device
drivers

No worries m8, there is a clean solution. Instead of using build, just write
a simple makefile. All you need to do is copy a few things from the build
log like the compiler & linker command lines. Then you have the flexibility
to layout your source files any way you want.

There are many other nice benefits to this approach. You can elimate the
meaningless diagnostic spew build spits out every time you compile your code
that buries warning messages. You can put your output files in a simple and
logical arrangement rather than the ridiculous subtree build makes. You can
auto sign your driver as a makefile step. Throughout my career I have noted
the makefile approach is preferred for driver craftsmen who put pride in
every area of their work because it can be tuned to meet any engineering
needs perfectly. Build on the other hand is a bit of a joke. Its limiting,
hard coded nature is also error prone. For instance, it is unbelievable to
me the WDK samples are such that if you change a MOF file and press build
that iit does not notice anything changed and does absolutely nothing.
Ridiculous.

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

OSR_Community_User · August 25, 2010, 4:37am

On 8/25/2010 2:49 AM, xxxxx@gmail.com wrote:

Throughout my career I have noted the makefile
approach is preferred for driver craftsmen […]
Build on the other hand is a bit of a joke. […]

Yeah. E.g., it builds everything with debug settings, even the release
versions. Stupid! Of course you would remove *that* in your makefile.

Much later, if (when!) you need them, then try to build debug symbols
matching your binaries.
Problem is: you probably can’t. (See other thread.)

=> Build.exe may be idiosyncratic, and it is certainly not perfect.
But at least it is aligned with all the other MS tools and source layout
idiosyncrasies. You work for the MS world, better keep consistent.