WDK7 custom target path

NTDEV
61

I think migration to MSBuild is far more likely than a significant reworking of the build/nmake/makefile system. A few years ago, I saw a post on a public forum from an MS developer, saying they were working on converting the Windows OS build process to MSBuild. It was quickly followed by a post from another MS developer telling the first guy to stop talking about internal projects. I don’t know if the project was canceled, or is still underway, but simply taking a really long time.

-----Original Message-----
From: Pavel A.
Sent: Monday, January 19, 2009 4:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

In other words, you want entirely make-based build system, like in Linux.
However, if MS were to break from their old good toolchain, they
could abandon the nmake and makefiles altogether, and go to something
completely different, like the .NET msbuild (nant-like)?

Regards,
–PA

62

I understand where the WDK comes from, but I draw a different conclusion. I think the internal build tools team should see it as their mission not to gratuitously break the WDK. This many years after the release of NT, they don’t get to act surprised that outside developers rely on their stuff. I’m not saying that makefile.new needs to be treated with the same back-compat respect as windows.h, but breaking changes should (1) be deliberate (not simply an accident), and (2) made because there was no good way to avoid it.

–John

63

Modifying setenv.bat is a bad idea, but I don’t see the problem with using another batch file to pre/post-process setenv. If setenv’s problems can be solved by invoking it with certain command line arguments, and/or setting certain environment variables, that seems a perfectly acceptable solution. This batch file would be checked in to source control with the driver code, so builds are repeatable. Am I missing something? What is your objection to this approach?

-----Original Message-----
From: Don Burn
Sent: Tuesday, January 20, 2009 11:45 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

How does one set it. It looks so far like the only way is to hack
setenv. That is not an acceptable solutuon in most companies.

64

Take a look at the new setenv, there is more to it than a post pre/post
process. Even if it was my stated goal was to come up with a schema that
would allow my clients to work the way they had in the past. Since many of
them choose a build environment by going to the start menu and pulling up
the WDK this needs to be workable. while I could pothentially live with some
post processing, the script is looking very ugly, and will break at the
first change to setenv.

You in another post objected to the build team breaking things. I do not
like it, but part of what I am trying to do is work around that. I can
forgive most changes to the environment if there is a workaround. In this
case, if the wrappers to binplace had not made things very hard to do, I
would have documented a sources file that would have done the correct thing
from DDK 3790.1830 to the new beta.

As a plea to Microsoft please as much as possible do not make these things
“add a new switch to setenv”, many people do not invoke setenv directly, we
either use the build environment shortcuts (and do not want to change them)
or use something like DDKBUILD. Most of us want any magic incorportated in
the SOURCES file, not in options in N different places.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“McNamee, John” <john.mcnamee> wrote in message news:xxxxx@ntdev…
Modifying setenv.bat is a bad idea, but I don’t see the problem with using
another batch file to pre/post-process setenv. If setenv’s problems can be
solved by invoking it with certain command line arguments, and/or setting
certain environment variables, that seems a perfectly acceptable solution.
This batch file would be checked in to source control with the driver code,
so builds are repeatable. Am I missing something? What is your objection
to this approach?

-----Original Message-----
From: Don Burn
Sent: Tuesday, January 20, 2009 11:45 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

How does one set it. It looks so far like the only way is to hack
setenv. That is not an acceptable solutuon in most companies.</john.mcnamee>

65

Don,

I know! We’ll build a file system filter driver that allows you to
create a shadow version of all the WDK content, so that modifications
are written to a separate location.

That would be a very lightweight solution to this complicated problem.
:wink:

OK, I’ll go crawl back to NTFSD now.

Tony
OSR

66

Tony - we can use this file system filter to modify the contents of the WDK on-the-fly :slight_smile:

I think a little bit humor will be good for all of us!

67

As long as you use the minifilter model, you can be sure it will work in future version of Windows.

Oh, wait… that was another thread.

Peter
OSR

68

Thanks Peter and Tony , very nice :-)!

69

Just to state the obvious, you can change these on the command line or
via another batch file. It’s not great, but it works, and certainly
beats modifying setenv.bat.

mm

xxxxx@microsoft.com wrote:

Thanks all for the feedback!

Binplace can do more, TARGETPATH will be restored. We will consider customizing the _NTTREE and intemediate output so they can be redirected as desired. Right now they are predefined in setenv.bat (_NTTREE and OBJECT_ROOT).

70

As long as we’re talking about (msft) modifying setenv.bat, how about
letting one run it in an existing build window? At the moment, it won’t
let you, which I personally have found very irritating while I’ve been
trying to figure out OBJECT_ROOT, et. c.

mm

Don Burn wrote:

Take a look at the new setenv, there is more to it than a post pre/post
process. Even if it was my stated goal was to come up with a schema that
would allow my clients to work the way they had in the past. Since many of
them choose a build environment by going to the start menu and pulling up
the WDK this needs to be workable. while I could pothentially live with some
post processing, the script is looking very ugly, and will break at the
first change to setenv.

You in another post objected to the build team breaking things. I do not
like it, but part of what I am trying to do is work around that. I can
forgive most changes to the environment if there is a workaround. In this
case, if the wrappers to binplace had not made things very hard to do, I
would have documented a sources file that would have done the correct thing
from DDK 3790.1830 to the new beta.

As a plea to Microsoft please as much as possible do not make these things
“add a new switch to setenv”, many people do not invoke setenv directly, we
either use the build environment shortcuts (and do not want to change them)
or use something like DDKBUILD. Most of us want any magic incorportated in
the SOURCES file, not in options in N different places.

71

Martin O’Brien wrote:

As long as we’re talking about (msft) modifying setenv.bat, how about
letting one run it in an existing build window? At the moment, it
won’t let you, which I personally have found very irritating while
I’ve been trying to figure out OBJECT_ROOT, et. c.

There are two good solutions to this. My “makeall” build scripts
basically do this:
setlocal
call %DDK%\bin\setenv %DDK% chk wxp
endlocal
setlocal
call %DDK%\bin\setenv %DDK% fre wxp
endlocal

“endlocal” restores the environment back to the last “setlocal”.

The other solution is:
set DDKBUILDENV=
That’s the key variable that the script looks for.

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

72

Thanks, Tim.

mm

Tim Roberts wrote:

Martin O’Brien wrote:
> As long as we’re talking about (msft) modifying setenv.bat, how about
> letting one run it in an existing build window? At the moment, it
> won’t let you, which I personally have found very irritating while
> I’ve been trying to figure out OBJECT_ROOT, et. c.

There are two good solutions to this. My “makeall” build scripts
basically do this:
setlocal
call %DDK%\bin\setenv %DDK% chk wxp
endlocal
setlocal
call %DDK%\bin\setenv %DDK% fre wxp
endlocal

“endlocal” restores the environment back to the last “setlocal”.

The other solution is:
set DDKBUILDENV=
That’s the key variable that the script looks for.

73

Or launch setenv.bat using cmd /k from within a command window. You can then exit that instance of cmd, which will dump all of its environment variable modifications, and start again.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, January 21, 2009 9:42 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WDK7 custom target path

Martin O’Brien wrote:

As long as we’re talking about (msft) modifying setenv.bat, how about
letting one run it in an existing build window? At the moment, it
won’t let you, which I personally have found very irritating while
I’ve been trying to figure out OBJECT_ROOT, et. c.

There are two good solutions to this. My “makeall” build scripts
basically do this:
setlocal
call %DDK%\bin\setenv %DDK% chk wxp
endlocal
setlocal
call %DDK%\bin\setenv %DDK% fre wxp
endlocal

“endlocal” restores the environment back to the last “setlocal”.

The other solution is:
set DDKBUILDENV=
That’s the key variable that the script looks for.

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

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

74

The key concept here is that MY build environment is irrelevant. What is
essential is that I can deliver to a customer a driver which they can
rebuild, at will, at any time, from a standard “checked build” or “free
build” environment, WITH NO MODIFICATIONS OR ADDITIONAL STEPS REQUIRED. I
cannot tell them to create new environment variables (which are global to
all projects and therefore destructive to modularization of projects), or
run special batch jobs to make the environment variables local to a command
session, or anything else. Therefore, EVERYTHING that affects the build
MUST be in the sources file or some equivalent configuration file which
exists in that project directory. Every output must be relative to that
project directory; there can be no “global” directories into which things
are written by default. All defaults must be project-local, and ONLY
project-local.

I face the same problem when I deliver products in user space that could
require using a special Platform SDK: I can only build with the
out-of-the-box environment that the customers use. If there’s some newer
PSDK feature that I need, I have to create a special header file in the
project that defines that feature and that feature alone, and which has
#ifdefs to detect if, for some accident of good fortune, that customer
happens to have a programmer that is using the latest PSDK. Yes, I’ve been
burned by this more than once, which is why I can only build with the OOTB
environment that my customers will have.

Therefore, no solution that involves modifying any part of the
out-of-the-box environment, including adding environment variables or adding
additional steps to the build procedure, would be acceptable. Customers can
be running multiple DDKs (or WDKs) on a per-project basis, and each
programmer might use two or three environments in the course of a week, or
even a day. Each project must build completely standalone in whatever the
selected environment is. All existing environments must be supportable
concurrently, and in fact I should be able to have two build sessions for
two completely different DDK/WDK environments compiling at exactly the same
time, each for a different project, with no problems encountered because I
have different DDK/WDK environments installed.

This illustrates once again the myth Microsoft likes to believe: that
everyone, for every driver, on every machine, in every site, uses ONLY the
very-latest-version of software, and every programmer has exactly one
project, and every project is identical. Alas, in the Real World this
doesn’t happen. Even in user space, I need to have VS6, VS2003, VS2005 and
VS2008 installed. And it is worth pointing out that Microsoft issued a
completely incompatible version of the Platform SDK for VS2005 such that if
you use it exclusively, VS2005 has an MTBF of under 5 minutes, and in some
cases, can’t work at all with some projects. Apparently PSDK and VS
environments are separate fiefdoms with little communication. Now it sounds
like the same thing is happening in the driver world.

joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, January 20, 2009 2:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:WDK7 custom target path

Take a look at the new setenv, there is more to it than a post pre/post
process. Even if it was my stated goal was to come up with a schema that
would allow my clients to work the way they had in the past. Since many of
them choose a build environment by going to the start menu and pulling up
the WDK this needs to be workable. while I could pothentially live with some
post processing, the script is looking very ugly, and will break at the
first change to setenv.

You in another post objected to the build team breaking things. I do not
like it, but part of what I am trying to do is work around that. I can
forgive most changes to the environment if there is a workaround. In this
case, if the wrappers to binplace had not made things very hard to do, I
would have documented a sources file that would have done the correct thing
from DDK 3790.1830 to the new beta.

As a plea to Microsoft please as much as possible do not make these things
“add a new switch to setenv”, many people do not invoke setenv directly, we
either use the build environment shortcuts (and do not want to change them)
or use something like DDKBUILD. Most of us want any magic incorportated in

the SOURCES file, not in options in N different places.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“McNamee, John” <john.mcnamee> wrote in message news:xxxxx@ntdev…
Modifying setenv.bat is a bad idea, but I don’t see the problem with using
another batch file to pre/post-process setenv. If setenv’s problems can be
solved by invoking it with certain command line arguments, and/or setting
certain environment variables, that seems a perfectly acceptable solution.
This batch file would be checked in to source control with the driver code,
so builds are repeatable. Am I missing something? What is your objection
to this approach?

-----Original Message-----
From: Don Burn
Sent: Tuesday, January 20, 2009 11:45 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

How does one set it. It looks so far like the only way is to hack
setenv. That is not an acceptable solutuon in most companies.

—
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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.</john.mcnamee>

75

Of course, you should also realize the inherent error in saying that “Microsoft believes that ”, as it’s a very large org with a lot of people in it, who aren’t copies of eachother. :slight_smile:

The ability to detect the SDK version was however frequently requested in the MVP chats when I was so involved, IIRC.

? S

-----Original Message-----
From: Joseph M. Newcomer
Sent: Wednesday, January 21, 2009 11:10
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:WDK7 custom target path

The key concept here is that MY build environment is irrelevant. What is
essential is that I can deliver to a customer a driver which they can
rebuild, at will, at any time, from a standard “checked build” or “free
build” environment, WITH NO MODIFICATIONS OR ADDITIONAL STEPS REQUIRED. I
cannot tell them to create new environment variables (which are global to
all projects and therefore destructive to modularization of projects), or
run special batch jobs to make the environment variables local to a command
session, or anything else. Therefore, EVERYTHING that affects the build
MUST be in the sources file or some equivalent configuration file which
exists in that project directory. Every output must be relative to that
project directory; there can be no “global” directories into which things
are written by default. All defaults must be project-local, and ONLY
project-local.

I face the same problem when I deliver products in user space that could
require using a special Platform SDK: I can only build with the
out-of-the-box environment that the customers use. If there’s some newer
PSDK feature that I need, I have to create a special header file in the
project that defines that feature and that feature alone, and which has
#ifdefs to detect if, for some accident of good fortune, that customer
happens to have a programmer that is using the latest PSDK. Yes, I’ve been
burned by this more than once, which is why I can only build with the OOTB
environment that my customers will have.

Therefore, no solution that involves modifying any part of the
out-of-the-box environment, including adding environment variables or adding
additional steps to the build procedure, would be acceptable. Customers can
be running multiple DDKs (or WDKs) on a per-project basis, and each
programmer might use two or three environments in the course of a week, or
even a day. Each project must build completely standalone in whatever the
selected environment is. All existing environments must be supportable
concurrently, and in fact I should be able to have two build sessions for
two completely different DDK/WDK environments compiling at exactly the same
time, each for a different project, with no problems encountered because I
have different DDK/WDK environments installed.

This illustrates once again the myth Microsoft likes to believe: that
everyone, for every driver, on every machine, in every site, uses ONLY the
very-latest-version of software, and every programmer has exactly one
project, and every project is identical. Alas, in the Real World this
doesn’t happen. Even in user space, I need to have VS6, VS2003, VS2005 and
VS2008 installed. And it is worth pointing out that Microsoft issued a
completely incompatible version of the Platform SDK for VS2005 such that if
you use it exclusively, VS2005 has an MTBF of under 5 minutes, and in some
cases, can’t work at all with some projects. Apparently PSDK and VS
environments are separate fiefdoms with little communication. Now it sounds
like the same thing is happening in the driver world.

joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, January 20, 2009 2:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:WDK7 custom target path

Take a look at the new setenv, there is more to it than a post pre/post
process. Even if it was my stated goal was to come up with a schema that
would allow my clients to work the way they had in the past. Since many of
them choose a build environment by going to the start menu and pulling up
the WDK this needs to be workable. while I could pothentially live with some
post processing, the script is looking very ugly, and will break at the
first change to setenv.

You in another post objected to the build team breaking things. I do not
like it, but part of what I am trying to do is work around that. I can
forgive most changes to the environment if there is a workaround. In this
case, if the wrappers to binplace had not made things very hard to do, I
would have documented a sources file that would have done the correct thing
from DDK 3790.1830 to the new beta.

As a plea to Microsoft please as much as possible do not make these things
“add a new switch to setenv”, many people do not invoke setenv directly, we
either use the build environment shortcuts (and do not want to change them)
or use something like DDKBUILD. Most of us want any magic incorportated in

the SOURCES file, not in options in N different places.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“McNamee, John” <john.mcnamee> wrote in message news:xxxxx@ntdev…
Modifying setenv.bat is a bad idea, but I don’t see the problem with using
another batch file to pre/post-process setenv. If setenv’s problems can be
solved by invoking it with certain command line arguments, and/or setting
certain environment variables, that seems a perfectly acceptable solution.
This batch file would be checked in to source control with the driver code,
so builds are repeatable. Am I missing something? What is your objection
to this approach?

-----Original Message-----
From: Don Burn
Sent: Tuesday, January 20, 2009 11:45 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

How does one set it. It looks so far like the only way is to hack
setenv. That is not an acceptable solutuon in most companies.

—
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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

—
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</john.mcnamee>

76

>Or launch setenv.bat using cmd /k from within a command window.

This is how the out-of-the-box start menu shortcuts work.

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

77

It’s one thing when a particular group “believes in ” and foists it off
on the customers. But when different groups begin to imitate each other,
adding similar features, deprecating existing features in incompatible ways,
removing features end users depend on, and generally wreaking havoc among
the customers, it’s hard not to call it a trend. I’m not extrapolating from
a single data point, here. VS, Office and the WDK all seem to be making a
philosophically consistent set of decisions, which is that it is OK to break
everything because the new solution is So Much Cooler. Worse still, they
deliberately remove the ability to use the old techniques, because The New
Way Is Better. Except that almost always, it is not actually better.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, January 21, 2009 8:55 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:WDK7 custom target path

Of course, you should also realize the inherent error in saying that
“Microsoft believes that ”, as it’s a very large org with a lot of people
in it, who aren’t copies of eachother. :slight_smile:

The ability to detect the SDK version was however frequently requested in
the MVP chats when I was so involved, IIRC.

- S

-----Original Message-----
From: Joseph M. Newcomer
Sent: Wednesday, January 21, 2009 11:10
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:WDK7 custom target path

The key concept here is that MY build environment is irrelevant. What is
essential is that I can deliver to a customer a driver which they can
rebuild, at will, at any time, from a standard “checked build” or “free
build” environment, WITH NO MODIFICATIONS OR ADDITIONAL STEPS REQUIRED. I
cannot tell them to create new environment variables (which are global to
all projects and therefore destructive to modularization of projects), or
run special batch jobs to make the environment variables local to a command
session, or anything else. Therefore, EVERYTHING that affects the build
MUST be in the sources file or some equivalent configuration file which
exists in that project directory. Every output must be relative to that
project directory; there can be no “global” directories into which things
are written by default. All defaults must be project-local, and ONLY
project-local.

I face the same problem when I deliver products in user space that could
require using a special Platform SDK: I can only build with the
out-of-the-box environment that the customers use. If there’s some newer
PSDK feature that I need, I have to create a special header file in the
project that defines that feature and that feature alone, and which has
#ifdefs to detect if, for some accident of good fortune, that customer
happens to have a programmer that is using the latest PSDK. Yes, I’ve been
burned by this more than once, which is why I can only build with the OOTB
environment that my customers will have.

Therefore, no solution that involves modifying any part of the
out-of-the-box environment, including adding environment variables or adding
additional steps to the build procedure, would be acceptable. Customers can
be running multiple DDKs (or WDKs) on a per-project basis, and each
programmer might use two or three environments in the course of a week, or
even a day. Each project must build completely standalone in whatever the
selected environment is. All existing environments must be supportable
concurrently, and in fact I should be able to have two build sessions for
two completely different DDK/WDK environments compiling at exactly the same
time, each for a different project, with no problems encountered because I
have different DDK/WDK environments installed.

This illustrates once again the myth Microsoft likes to believe: that
everyone, for every driver, on every machine, in every site, uses ONLY the
very-latest-version of software, and every programmer has exactly one
project, and every project is identical. Alas, in the Real World this
doesn’t happen. Even in user space, I need to have VS6, VS2003, VS2005 and
VS2008 installed. And it is worth pointing out that Microsoft issued a
completely incompatible version of the Platform SDK for VS2005 such that if
you use it exclusively, VS2005 has an MTBF of under 5 minutes, and in some
cases, can’t work at all with some projects. Apparently PSDK and VS
environments are separate fiefdoms with little communication. Now it sounds
like the same thing is happening in the driver world.

joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, January 20, 2009 2:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:WDK7 custom target path

Take a look at the new setenv, there is more to it than a post pre/post
process. Even if it was my stated goal was to come up with a schema that
would allow my clients to work the way they had in the past. Since many of
them choose a build environment by going to the start menu and pulling up
the WDK this needs to be workable. while I could pothentially live with some
post processing, the script is looking very ugly, and will break at the
first change to setenv.

You in another post objected to the build team breaking things. I do not
like it, but part of what I am trying to do is work around that. I can
forgive most changes to the environment if there is a workaround. In this
case, if the wrappers to binplace had not made things very hard to do, I
would have documented a sources file that would have done the correct thing
from DDK 3790.1830 to the new beta.

As a plea to Microsoft please as much as possible do not make these things
“add a new switch to setenv”, many people do not invoke setenv directly, we
either use the build environment shortcuts (and do not want to change them)
or use something like DDKBUILD. Most of us want any magic incorportated in

the SOURCES file, not in options in N different places.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“McNamee, John” <john.mcnamee> wrote in message news:xxxxx@ntdev…
Modifying setenv.bat is a bad idea, but I don’t see the problem with using
another batch file to pre/post-process setenv. If setenv’s problems can be
solved by invoking it with certain command line arguments, and/or setting
certain environment variables, that seems a perfectly acceptable solution.
This batch file would be checked in to source control with the driver code,
so builds are repeatable. Am I missing something? What is your objection
to this approach?

-----Original Message-----
From: Don Burn
Sent: Tuesday, January 20, 2009 11:45 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

How does one set it. It looks so far like the only way is to hack
setenv. That is not an acceptable solutuon in most companies.

—
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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

—
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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.</john.mcnamee>

78

THIS is ABSOLUTELY correct. (see more below)

THIS amounts to little more than a rant.

The belief that everyone’s using the latest and greatest stems not out of animus, stupidity, or even the desire to bludgeon people to buy new stuff… but rather from the internal reality of how folks at Microsoft work. Everyone IS only working with the latest version of the software, usually the next unreleased version of the software (whether that’s Windows, the WDK, VS, or Office). Except for the folks who do work on bug-fixing down-level platforms (sustained engineering), if you work on (say) Windows you’re solely and completely focused right now on Windows 7. You’ve been running Windows 7 on your primary dev box, doing your daily work with it, for what feels like a really long time. It does not seem “new” to you. Vista is old hat. And Windows XP feels like really ancient history.

I’m not explaining this to try to EXCUSE stuff breaking down-level in, for example, build environments. Rather, I’m trying to EXPLAIN why it happens.

The first step toward being able to change something is understanding how the thing you want changed came to be.

Finally… consider things that *really* matter like O/S behaviors and down-rev DDIs. When’s the last time you saw a DDI actually removed from Windows? Or the behavior significantly changed? The only ones I can think of are the HAL/bus related functions from NT V4 and earlier.

I don’t think the claim that Microsoft feels “it is OK to break everything because the new solution is So Much Cooler” is anywhere close to true.

Peter
OSR

79

Agreed.
As IHV partner, I work on campus sometimes. Folks at msft use absolutely the?bleeding edge of everything you can imagine. Some?laughed at me when they saw?my laptop running wxp/outlook2003 and suggested I should trash?it and get a new one-;)?

Calvin Guan
Broadcom Corp.
Connecting Everything(r)

?
----- Original Message ----
From: “xxxxx@osr.com”
To: Windows System Software Devs Interest List
Sent: Thursday, January 22, 2009 9:15:00 AM
Subject: RE:[ntdev] WDK7 custom target path



THIS is ABSOLUTELY correct.? (see more below)



THIS amounts to little more than a rant.

The belief that everyone’s using the latest and greatest stems not? out of animus, stupidity, or even the desire to bludgeon people to buy new stuff…? but rather from the internal reality of how folks at Microsoft work.? Everyone IS only working with the latest version of the software, usually the next unreleased version of the software (whether that’s Windows, the WDK, VS, or Office).? Except for the folks who do work on bug-fixing down-level platforms (sustained engineering), if you work on (say) Windows you’re solely and completely focused right now on Windows 7.? You’ve been running Windows 7 on your primary dev box, doing your daily work with it, for what feels like a really long time.? It does not seem “new” to you.? Vista is old hat.? And Windows XP feels like really ancient history.

I’m not explaining this to try to EXCUSE stuff breaking down-level in, for example, build environments.? Rather, I’m trying to EXPLAIN why it happens.

The first step toward being able to change something is understanding how the thing you want changed came to be.

Finally… consider things that really matter like O/S behaviors and down-rev DDIs.? When’s the last time you saw a DDI actually removed from Windows?? Or the behavior significantly changed?? The only ones I can think of are the HAL/bus related functions from NT V4 and earlier.

I don’t think the claim that Microsoft feels “it is OK to break everything because the new solution is So Much Cooler” is anywhere close to true.

Peter
OSR

—
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

80

I’m sorry, Calvin, but not even you see everything or everyone’s working methods.

WDF has to work on all those crufty old OS, and pretty much everyone on this team has machines running everything (Win2K is rare, because it is a security risk to attach it to the corporate network- one severe enough to cause you to lose the privilege of attaching to it) at one time or another. In my case, I’ve been running Win7 on my primary development machine pretty much constantly for the last two years, because that’s part of my duty in getting Windows 7 out there- but I’ve had plenty of testing time on everything else (including Win2K) over that period of time.

The same (perhaps abstracting particulars based upon each team’s needs) is true of most other organizations I have contact with, particularly in test. I am aware there are cases where the statement Peter originally advanced is justified, but as is usually the case- no generalization is true [I’ll even add the obligatory “including this one”].

I’ve seen this divide from both sides over the last couple of decades- neither one fully understands the other. Then again- isn’t that true of most complex relationships?