WDK7 custom target path

I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported in WDK7.
BUILD_ALT_DIR still works but this always prefixes “obj” to my target path
which is not desired. All the very complicated documentation that’s in
“specifying the location of created files” now seems no longer valid.

It’s very useful to be able to choose a custom output dir the question how
should this be achieved ?

//Daniel

Doc:
Use the TARGETPATH macro to specify the destination directory for all build
products.
You must have this macro in your sources file.

Build:
Errors in directory:
error U1050: s:\sys TARGETPATH is no longer allowed. Remove it.

>I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported in WDK7.

I second this.

TARGETPATH is a very important feature which allows to build lots of EXE/DLL/SYS files using one “build” command, and then to place all of them to a single directory for convinience.

Also, I use LIB files for intermediate stages of BUILD, and putting them to a single directory using TARGETPATH is a good idea again.

People do really use TARGETPATH. It is a good thing, and too bad it is removed from Win7 DDK beta.

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

As an FYI to folks who don’t normally read NTFSD, a post was made about how
good WDK7 was, which has lead to a number of posts on how bad it is
including this topic.

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

wrote in message news:xxxxx@ntdev…
>I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported in WDK7.
>BUILD_ALT_DIR still works but this always prefixes “obj” to my target path
>which is not desired. All the very complicated documentation that’s in
>“specifying the location of created files” now seems no longer valid.
>
> It’s very useful to be able to choose a custom output dir the question how
> should this be achieved ?
>
> //Daniel
>
>
> ----
> Doc:
> Use the TARGETPATH macro to specify the destination directory for all
> build products.
> You must have this macro in your sources file.
>
> Build:
> Errors in directory:
> error U1050: s:\sys TARGETPATH is no longer allowed. Remove it.
>

Define “too bad”? Does this mean the same thing as “completely
irresponsible”? Sounds like it to me.

How is it that seem to be in an abusive co-dependent relationship with
whomever is deciding these changes make sense?
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Saturday, January 17, 2009 2:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported in WDK7.

I second this.

TARGETPATH is a very important feature which allows to build lots of
EXE/DLL/SYS files using one “build” command, and then to place all of them
to a single directory for convinience.

Also, I use LIB files for intermediate stages of BUILD, and putting them to
a single directory using TARGETPATH is a good idea again.

People do really use TARGETPATH. It is a good thing, and too bad it is
removed from Win7 DDK beta.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.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

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

I’ve never used TARGETPATH, and I don’t really use build itself much
either, but I’ve had read that documentation, and I’m surprised it ever
worked, because the combination of it being so incredibly complicated as
well about nothing more than a bunch of macros, has always caused me to
assume that just couldn’t possibly work. I mean, if it was important to
them to let you specify where you would like targets produced, they’d
just let you say something like ‘OUT=’ and that would be about it.

In any case, yeah that’s really irritating that they broke it, whether
intentionally or not. I suspect not, and I know that this isn’t much
help, but as a place to start, I would search ‘makefile.def’ for
‘separate_object_root’ and see what you find. In case you don’t know,
‘separate_object_root’ is one of the environment variables that controls
whether things are built under the src directory as before, or in some
global location, which is not really safe, in my opinion, in the case of
the defaults.

Good luck,

mm

xxxxx@resplendence.com wrote:

I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported in
WDK7. BUILD_ALT_DIR still works but this always prefixes “obj” to my
target path which is not desired. All the very complicated documentation
that’s in “specifying the location of created files” now seems no longer
valid.

It’s very useful to be able to choose a custom output dir the question
how should this be achieved ?

//Daniel

---

Doc:
Use the TARGETPATH macro to specify the destination directory for all
build products.
You must have this macro in your sources file.

Build:
Errors in directory:
error U1050: s:\sys TARGETPATH is no longer allowed. Remove it.

Hi guys,

TARGETPATH (and TARGETPATHLIB) were deprecated in WDK beta because of Win7 changes in build.exe. I am sorry the documentation is a little bit late, but I can ensure you the update will be there soon.

I would like to make sure we understand the user scenarious that you addrees which were hit by this change so we consider them timely.

Daniel: about the custom tharget path - what do you mean by choosing a custom output dir? Is this the TARGETPATH that you think about? I see Max addressed this issue too. Or is it a complitely new path, not relative to source path?

So far TARGETPATH enabled custom OBJ_PATH directories to be set. For example:

Source code in: c:\WinDDK\base\abc\project
TARGETPATH set to: base\abc\project$O
Output will result in: c:\WinDDK\base\abc\project\objfre\i386

Let’s start the discussion from here and thanks for the valuabl? feedback!

Tanya

Have you looked at BINPLACE? That will copy the resulting bins in whatever dir you want independent of where the compiler generated the binary. Seems to me you can just replace targetpath with it

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Maxim S. Shatskih
Sent: Saturday, January 17, 2009 11:52 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

>I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported in WDK7.

I second this.

TARGETPATH is a very important feature which allows to build lots of EXE/DLL/SYS files using one “build” command, and then to place all of them to a single directory for convinience.

Also, I use LIB files for intermediate stages of BUILD, and putting them to a single directory using TARGETPATH is a good idea again.

People do really use TARGETPATH. It is a good thing, and too bad it is removed from Win7 DDK beta.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.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

Yes, Binplace sample is a good alternative to what you want to achieve - binaries placed in a custom folder.

To turn on that just add separate_object_root flag as setenv.bat parameter.

Then you specify TARGET_DESTINATION = customfolder

The result:

Source code in: c:\WinDDK\base\abc\project
TARGET_DESTINATION = customfolder
Output will result in: c:\WinDDK.binaries..\customfolder

I suspect binplace is a better approach, but the problem is that it still is
a change, and having a change leads to several problems:

1. Getting my clients to use the beta. Since they have to change
   their working code to try the beta they are much less likely to try it,
   especially since most of them are in cycles of getting out new drivers

2. Backwards compatibility is broken. I still have clients who build
   some drivers with 3790.1830 because they have not had justification to move
   forward. Even for these customers I push them to run the latest prefast on
   the driver and validate things, but here it means keeping a SOURCES for the
   old environment and a SOURCES for the new environment.

Please remember any change has consequences, and these changes have in some
cases made clients reluctant to take the step to better tools.

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

wrote in message news:xxxxx@ntdev…
> Yes, Binplace sample is a good alternative to what you want to achieve -
> binaries placed in a custom folder.
>
> To turn on that just add separate_object_root flag as setenv.bat
> parameter.
>
> Then you specify TARGET_DESTINATION = customfolder
>
> The result:
>
> Source code in: c:\WinDDK\base\abc\project
> TARGET_DESTINATION = customfolder
> Output will result in: c:\WinDDK.binaries..\customfolder
>
>

Doron

Can you give one good reason for removal of TARGETPATH?

Thanks, Lyndon

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Have you looked at BINPLACE? That will copy the resulting bins in whatever
dir you want independent of where the compiler generated the binary. Seems
to me you can just replace targetpath with it

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Maxim S. Shatskih
Sent: Saturday, January 17, 2009 11:52 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

>I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported in WDK7.

I second this.

TARGETPATH is a very important feature which allows to build lots of
EXE/DLL/SYS files using one “build” command, and then to place all of them
to a single directory for convinience.

Also, I use LIB files for intermediate stages of BUILD, and putting them to
a single directory using TARGETPATH is a good idea again.

People do really use TARGETPATH. It is a good thing, and too bad it is
removed from Win7 DDK beta.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.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

It seems they changed build.exe. I’ve never quite understood what build.exe
was doing for me other than being a block-box standing in the way of just
using makefiles to build stuff. Now it seems it really does have some use:
it randomly changes and in doing so forces developers all around the planet
to change working processes for building software.

Mark Roddy

On Sat, Jan 17, 2009 at 8:21 PM, Lyndon J Clarke > wrote:

> Doron
>
> Can you give one good reason for removal of TARGETPATH?
>
> Thanks, Lyndon
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> Have you looked at BINPLACE? That will copy the resulting bins in whatever
> dir you want independent of where the compiler generated the binary. Seems
> to me you can just replace targetpath with it
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not intentional.
>
> -----Original Message-----
> From: Maxim S. Shatskih
> Sent: Saturday, January 17, 2009 11:52 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] WDK7 custom target path
>
>
> >I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported in WDK7.
>
> I second this.
>
> TARGETPATH is a very important feature which allows to build lots of
> EXE/DLL/SYS files using one “build” command, and then to place all of them
> to a single directory for convinience.
>
> Also, I use LIB files for intermediate stages of BUILD, and putting them to
> a single directory using TARGETPATH is a good idea again.
>
> People do really use TARGETPATH. It is a good thing, and too bad it is
> removed from Win7 DDK beta.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.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
>
>
>
>
> —
> 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
>

I can give you a source code example:

With enabling separate_object_root and introducing OBJECT_ROOT macro the OBJECT_ROOT macro simply replaces TARGETPATH.

There is basically duplication in the behaviour and cases in which if OBJECT_ROOT enabled, TARGETPATH can mess up things:

Example:

separate_object_root is set
WDK installed in c:\WinDDK
Since OBJECT_ROOT is %BASEDIR%.obj,
then OBJ_ROOT will be
OBJECT_ROOT=c:\WinDDK.obj

Scenario:

Source code in: d:\WinDDK\base\xyz\project

TARGETPATH is set to base\abc\project$O

OBJ_PATH and resulting output will be:

c:\WinDDK.obj\base\abc\project\objfre\i386

instead of here:

c:\WinDDK.obj\base\xyz\project\objfre\i386

It is very importanc scenario ina a huge projects, but lafter we’ve got your feedback and we see the impact on a small to medium side project we are considering restoring the TARGETPATH macro.

Thanks all of you for the constructive feedback!

Tanya

Sorry for the typo:

It is very important scenario in a huge projects, but later after we’ve got your
feedback and we saw the impact on small to medium size project we are
considering to restore the TARGETPATH macro.

Thanks all of you for the constructive feedback!

Tanya

I find that I repeat myself a lot.

For the umpteen millionth time: The WDK build environment is just a mini version of the internal build environment that the Windows group uses to build all of Windows. This includes the compiler, linker, build, makefile.new, binplace, and even OACR.

The WDK team doesn’t create the overall build environment. It re-packages it, does some amount of customization, adds the things that allow support for multiple O/S versions, and releases it. (note that this isn’t the ONLY thing the WDK team does… they do a heck of a lot more… but it’s what they do with the basic build environment tools we’re discussing in this thread).

*Generally speaking*, the fact that the build environment is a mini version of the internal build environment used to build Windows is A Very Good Thing ™. An EXTREMELY Good Thing ™ in fact. The result is that when you build your driver, your’re building it with exactly the same set of tools that has been used to build the version of Windows for which you’re building your driver. Thus, you’re using a set of base tools that have been extensively and exhaustively tested by building umpteen builds of Windows before these base tools are released in the WDK.

The BAD part of this is that build environment and tools changes that are adopted in the Windows group (often for purposes that have little or nothing to do with the WDK or even driver development in general) “just appear” out of the blue… often with little explanation or warning… to us developers in the community.

So… it’s not like the WDK team sat down one day and said: “You know, we know better than the community, so let’s change the build utility because that would be a good thing for the driver development community.” They’re the recipients of these changes from the Windows team.

Since the community inherits the build environment that’s used to build WIndows, that means it’s more difficult for the WDK team to make major changes to the base tools in the WDK build environment. Do you REALLY want a build environment that diverges significantly from that used to build the OS?? I know that *I* sure don’t.

Peter
OSR

That was exactly the case.

Thank you very much Peter for your understanding and support!

Tanya

I agree whole heartedly with Peter that building IHV/ISV drivers with the
very same tool-set is critically important.

I just wish that there were perhaps a more ‘communicative’ approach to
having changes arrive in the tools. Maybe beta builds of the WDK are just
that and I should just provide feedback on the alias in hopes that the “oh,
so you were using *that*” response implies a vote for putting it back.
TARGETPATH falls into that category because *yes* I use that (principally
because I was too darn lazy to figure out BINPLACE for which I no longer
have an excuse).

But Don’s illustration of ‘preventing drop-in adoption’ because the kit
itself requires build system work that breaks using earlier kits rings true
with me as well.

My favorite illustration of this nonsense is the removal of amd64 and
replacement with x64 as an argument to setenv.bat that rolled into the WDK
rather silently. Now *that* would have been an absolute no-brainer to
support both switches and not break Mark’s or OSR’s DDKBUILD.BAT in a
multiple kit scenario.

So yeah, TARGETPATH might not be the battle to pick but it does mean *some*
amount of work to build processes will be necessary to just *test* the WDK
where it has been used. Maybe those changes are for the good. The problem
is that nobody has yet illustrated and explained why TARGETPATH is now such
a bad idea where it had survived quite usable for over a decade of kits.

And what *are* the changes in BUILD - aka, what should we be asking about
that we can only discover by being blind-sided by the new kit? We are
black-box testers here. The sanitized release notes for the kit don?t offer
much insight to the changes and the reasoning behind them.

David R. Cattley
Consulting Engineer
Systems Software Development

I agree wholeheartedly.

So, here’s an open invitation to the WDK Team (and also the team in the Windows group that is responsible for the Windows build environment): ANY time there are changes in the build environment that will be shipped in the WDK – small ones, medium ones, big ones, trivial ones or important ones – we at OSR will be VERY HAPPY to have you post that list here, have you guys (or one of our staff) write an article for The NT Insider describing the changes, and/or put a notice on OSROnline.

You can even report the changes piecemeal – one at a time – whenever you notice them, if that’s helpful. We can later work with you to put together a more comprehensive, cogent, list describing these changes and publish it.

At least then, the info will get out to the community.

Peter
OSR

You make some good points. The strongest action item for me is that we (the wdk team) have a better communication channel with the windows build team and we doc build related changes in the wdk for you guys to see.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: David R. Cattley
Sent: Sunday, January 18, 2009 10:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDK7 custom target path

I agree whole heartedly with Peter that building IHV/ISV drivers with the
very same tool-set is critically important.

I just wish that there were perhaps a more ‘communicative’ approach to
having changes arrive in the tools. Maybe beta builds of the WDK are just
that and I should just provide feedback on the alias in hopes that the “oh,
so you were using that” response implies a vote for putting it back.
TARGETPATH falls into that category because yes I use that (principally
because I was too darn lazy to figure out BINPLACE for which I no longer
have an excuse).

But Don’s illustration of ‘preventing drop-in adoption’ because the kit
itself requires build system work that breaks using earlier kits rings true
with me as well.

My favorite illustration of this nonsense is the removal of amd64 and
replacement with x64 as an argument to setenv.bat that rolled into the WDK
rather silently. Now that would have been an absolute no-brainer to
support both switches and not break Mark’s or OSR’s DDKBUILD.BAT in a
multiple kit scenario.

So yeah, TARGETPATH might not be the battle to pick but it does mean some
amount of work to build processes will be necessary to just test the WDK
where it has been used. Maybe those changes are for the good. The problem
is that nobody has yet illustrated and explained why TARGETPATH is now such
a bad idea where it had survived quite usable for over a decade of kits.

And what are the changes in BUILD - aka, what should we be asking about
that we can only discover by being blind-sided by the new kit? We are
black-box testers here. The sanitized release notes for the kit don?t offer
much insight to the changes and the reasoning behind them.

David R. Cattley
Consulting Engineer
Systems Software Development

—
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

Doron,

And please as part of that consider if there are ways to make
conditional the changes needed to the files, so that while some of us have
one foot in the future and one in the past, we can do this with the same
file set. Trying to tell my customers I need to modify their files to make
things work with a beta WDK is much easier, if I can state, but everything
will still work with your current environment. Saying we want to have two
files around is a much harder sell.

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

“Doron Holan” wrote in message
news:xxxxx@ntdev…
You make some good points. The strongest action item for me is that we (the
wdk team) have a better communication channel with the windows build team
and we doc build related changes in the wdk for you guys to see.

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: David R. Cattley
Sent: Sunday, January 18, 2009 10:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDK7 custom target path

I agree whole heartedly with Peter that building IHV/ISV drivers with the
very same tool-set is critically important.

I just wish that there were perhaps a more ‘communicative’ approach to
having changes arrive in the tools. Maybe beta builds of the WDK are just
that and I should just provide feedback on the alias in hopes that the “oh,
so you were using that” response implies a vote for putting it back.
TARGETPATH falls into that category because yes I use that (principally
because I was too darn lazy to figure out BINPLACE for which I no longer
have an excuse).

But Don’s illustration of ‘preventing drop-in adoption’ because the kit
itself requires build system work that breaks using earlier kits rings true
with me as well.

My favorite illustration of this nonsense is the removal of amd64 and
replacement with x64 as an argument to setenv.bat that rolled into the WDK
rather silently. Now that would have been an absolute no-brainer to
support both switches and not break Mark’s or OSR’s DDKBUILD.BAT in a
multiple kit scenario.

So yeah, TARGETPATH might not be the battle to pick but it does mean some
amount of work to build processes will be necessary to just test the WDK
where it has been used. Maybe those changes are for the good. The problem
is that nobody has yet illustrated and explained why TARGETPATH is now such
a bad idea where it had survived quite usable for over a decade of kits.

And what are the changes in BUILD - aka, what should we be asking about
that we can only discover by being blind-sided by the new kit? We are
black-box testers here. The sanitized release notes for the kit don’t offer
much insight to the changes and the reasoning behind them.

David R. Cattley
Consulting Engineer
Systems Software Development

—
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

One reason I dropped out of Microsoft beta programs years ago is that I
would raise these issues, such as “The GUI is unusable” or “This critical
feature no longer works”, and I was told “This is by design”. That is,
“beta” testing was only to find bugs in the product *as delivered*, not bugs
relative to, let’s say, bad design decisions. The product was assumed to be
perfect in design, and all they wanted to know was “does it work right when
used in the way we designed it?” rather than “does this meet your needs?” or
“is this product worth releasing at all in its current form?” It was a
given that questioning the design was outside the scope of the beta tester’s
acceptable responses, and after a few years of this, I stopped testing.

It didn’t help that I was sent the beta of, say, “Chicago”, not of “The next
MS-DOS-based Windows Release” (Yes, most of us knew “Chicago” by that point,
but, for example, I just learned that “groove” has something to do with
laptop synchronization and nothing to do with, say, Zune players). The
betas were sent out without any information describing what the product was,
what it would do for use, why we might want to test it, etc. All we got was
the internal project name! At least for WDK, we have some idea of the
purpose of the product!

Either Microsoft needs to re-evaluate what they mean by “beta testing” or
get the professional users in the loop much earlier so we don’t have to
fight the broken-as-designed (BAD) software issues after the fact.

joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Sunday, January 18, 2009 1:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDK7 custom target path

I agree whole heartedly with Peter that building IHV/ISV drivers with the
very same tool-set is critically important.

I just wish that there were perhaps a more ‘communicative’ approach to
having changes arrive in the tools. Maybe beta builds of the WDK are just
that and I should just provide feedback on the alias in hopes that the “oh,
so you were using *that*” response implies a vote for putting it back.
TARGETPATH falls into that category because *yes* I use that (principally
because I was too darn lazy to figure out BINPLACE for which I no longer
have an excuse).

But Don’s illustration of ‘preventing drop-in adoption’ because the kit
itself requires build system work that breaks using earlier kits rings true
with me as well.

My favorite illustration of this nonsense is the removal of amd64 and
replacement with x64 as an argument to setenv.bat that rolled into the WDK
rather silently. Now *that* would have been an absolute no-brainer to
support both switches and not break Mark’s or OSR’s DDKBUILD.BAT in a
multiple kit scenario.

So yeah, TARGETPATH might not be the battle to pick but it does mean *some*
amount of work to build processes will be necessary to just *test* the WDK
where it has been used. Maybe those changes are for the good. The problem
is that nobody has yet illustrated and explained why TARGETPATH is now such
a bad idea where it had survived quite usable for over a decade of kits.

And what *are* the changes in BUILD - aka, what should we be asking about
that we can only discover by being blind-sided by the new kit? We are
black-box testers here. The sanitized release notes for the kit don’t offer
much insight to the changes and the reasoning behind them.

David R. Cattley
Consulting Engineer
Systems Software Development

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.