I am trying to determine the ‘correct’ way of establishing the build
environment for compilation of a filesystem driver in Windows 2000. Near as
I can tell, there are conflicts with Microsoft’s SDK and DDK “setenv”
scripts.
-
If I execute the ‘setenv.bat’ from the Windows 2000 DDK, the INCLUDE
environment variable is configured with the DDK ‘inc’ directory preceding of
the compiler’s ‘include’ directory. The Platform SDK is ignored. (Expected
behaviour)
-
If I execute the ‘setenv.bat’ from the Platform SDK (February 2001), the
INCLUDE environment variable is configured with the SDK ‘include’ directory
preceding the compiler’s ‘include’ directory. The Windows 2000 DDK is
ignored. (Expected behaviour)
-
If I execute the ‘setenv.bat’ from the Platform SDK and then the
‘setenv.bat’ from the Windows 2000 DDK, the INCLUDE path order is DDK,
compiler, SDK. This, to me, is incorrect. I would have expected DDK, SDK,
compiler.
My problem arises when I need to use <security.h> from the Platform SDK when
compiling a filesystem driver. Given the INCLUDE path configuration,
<security.h> is used from the compiler which conflicts with another header
file in the DDK. If I manually override the INCLUDE environment variable,
the compiler uses the correct version (as expected).
While it is no problem to change these batch files to behave as I would
expect, I would rather not have to do this for each and every machine with
the SDK/DDK installed nor for every new version of the SDK/DDK
What is everybody else doing in this respect?
Much appreciated,
Mike.
—
Mike Frisch
Software Engineer, Connectivity
Hummingbird Ltd. (www.hummingbird.com)
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</security.h></security.h>
See KB Article ID: Q263993 “Info: Environments to Build Drivers”. It gives a very detailed descriptions of just what you are looking for.
Stacey
----- Original Message -----
From: Mike Frisch
To: NT Developers Interest List
Sent: Tuesday, May 01, 2001 7:09 AM
Subject: [ntdev] Build environment issues
I am trying to determine the ‘correct’ way of establishing the build
environment for compilation of a filesystem driver in Windows 2000. Near as
I can tell, there are conflicts with Microsoft’s SDK and DDK “setenv”
scripts.
-
If I execute the ‘setenv.bat’ from the Windows 2000 DDK, the INCLUDE
environment variable is configured with the DDK ‘inc’ directory preceding of
the compiler’s ‘include’ directory. The Platform SDK is ignored. (Expected
behaviour)
-
If I execute the ‘setenv.bat’ from the Platform SDK (February 2001), the
INCLUDE environment variable is configured with the SDK ‘include’ directory
preceding the compiler’s ‘include’ directory. The Windows 2000 DDK is
ignored. (Expected behaviour)
-
If I execute the ‘setenv.bat’ from the Platform SDK and then the
‘setenv.bat’ from the Windows 2000 DDK, the INCLUDE path order is DDK,
compiler, SDK. This, to me, is incorrect. I would have expected DDK, SDK,
compiler.
My problem arises when I need to use <security.h> from the Platform SDK when
compiling a filesystem driver. Given the INCLUDE path configuration,
<security.h> is used from the compiler which conflicts with another header
file in the DDK. If I manually override the INCLUDE environment variable,
the compiler uses the correct version (as expected).
While it is no problem to change these batch files to behave as I would
expect, I would rather not have to do this for each and every machine with
the SDK/DDK installed nor for every new version of the SDK/DDK
What is everybody else doing in this respect?
Much appreciated,
Mike.
—
Mike Frisch
Software Engineer, Connectivity
Hummingbird Ltd. (www.hummingbird.com)
—
You are currently subscribed to ntdev as: xxxxx@qwest.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</security.h></security.h>