DDKBUILD Update

DDKBUILD Update.

DDKBUILD version 3.12.35 is available for download from www.hollistech.com.
This minor update adds support for WDF beta 3 kernel mode windows driver
foundation builds (WDF version 5054.)

The direct link is:
http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

I just finished my first round of testing with this new version —
Env is -
VS8 beta 1.
ddk 3790.1830
wdf 5054.

Only thing I had to do ( well of course without reading Mark’s doc
thoroughly :slight_smile: is to plug this in sources -

WDF_ROOT=C:\WINDDK\WDF\01.00.5054

Everything is fine.

Thanks Mark !

-pro

----- Original Message -----
From: “Mark Roddy”
To: “Windows System Software Devs Interest List”
Sent: Sunday, May 08, 2005 8:59 AM
Subject: [ntdev] DDKBUILD Update

> DDKBUILD Update.
>
>
> DDKBUILD version 3.12.35 is available for download from
> www.hollistech.com.
> This minor update adds support for WDF beta 3 kernel mode windows driver
> foundation builds (WDF version 5054.)
>
> The direct link is:
> http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Set_wdf_env.cmd does this for you.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Sunday, May 08, 2005 9:47 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DDKBUILD Update

I just finished my first round of testing with this new version —
Env is -
VS8 beta 1.
ddk 3790.1830
wdf 5054.

Only thing I had to do ( well of course without reading Mark’s doc
thoroughly :slight_smile: is to plug this in sources -

WDF_ROOT=C:\WINDDK\WDF\01.00.5054

Everything is fine.

Thanks Mark !

-pro

----- Original Message -----
From: “Mark Roddy”
To: “Windows System Software Devs Interest List”
Sent: Sunday, May 08, 2005 8:59 AM
Subject: [ntdev] DDKBUILD Update

> DDKBUILD Update.
>
>
> DDKBUILD version 3.12.35 is available for download from
> www.hollistech.com.
> This minor update adds support for WDF beta 3 kernel mode windows
driver
> foundation builds (WDF version 5054.)
>
> The direct link is:
> http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> Set_wdf_env.cmd does this for you.

d

Well the problem is that ddkbuild has to know where “set_wdf_env.cmd” is in
order to run it. That problem is solved by requiring that WDF_ROOT is set
before invoking ddkbuild. A bit circular, but what could I do? Anyhow one
gets the remainder of set_wdf_env done for you.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Sunday, May 08, 2005 2:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKBUILD Update

Set_wdf_env.cmd does this for you.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Sunday, May 08, 2005 9:47 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DDKBUILD Update

I just finished my first round of testing with this new
version — Env is -
VS8 beta 1.
ddk 3790.1830
wdf 5054.

Only thing I had to do ( well of course without reading
Mark’s doc thoroughly :slight_smile: is to plug this in sources -

WDF_ROOT=C:\WINDDK\WDF\01.00.5054

Everything is fine.

Thanks Mark !

-pro

----- Original Message -----
From: “Mark Roddy”
> To: “Windows System Software Devs Interest List”
> Sent: Sunday, May 08, 2005 8:59 AM
> Subject: [ntdev] DDKBUILD Update
>
>
> > DDKBUILD Update.
> >
> >
> > DDKBUILD version 3.12.35 is available for download from
> > www.hollistech.com.
> > This minor update adds support for WDF beta 3 kernel mode windows
> driver
> > foundation builds (WDF version 5054.)
> >
> > The direct link is:
> > http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
> >
> > =====================
> > Mark Roddy
> > Windows .NET/XP/2000 Consulting
> > Hollis Technology Solutions 603-321-1032
> > www.hollistech.com
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

This much I can live with, given that the benifits I get out of ddkbuild.
And of course, I could have set this in global env. vars, but I would much
rather prefer to drop that one to the cmd line args for ddk build that I
mentioned to Mark couple weeks ago. To me getting out of workspace and
reactivate to get the latest env. is bit of a work. Sorry Mark, I’m the
laziest you would ever encounter :slight_smile:

BTW, the BSC is even a big bonus.

-pro

----- Original Message -----
From: “Mark Roddy”
To: “Windows System Software Devs Interest List”
Sent: Sunday, May 08, 2005 11:56 AM
Subject: RE: [ntdev] DDKBUILD Update

>> Set_wdf_env.cmd does this for you.
>>
>> d
>
> Well the problem is that ddkbuild has to know where “set_wdf_env.cmd” is
> in
> order to run it. That problem is solved by requiring that WDF_ROOT is set
> before invoking ddkbuild. A bit circular, but what could I do? Anyhow one
> gets the remainder of set_wdf_env done for you.
>
>
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
>> Sent: Sunday, May 08, 2005 2:07 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] DDKBUILD Update
>>
>> Set_wdf_env.cmd does this for you.
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
>> Sent: Sunday, May 08, 2005 9:47 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] DDKBUILD Update
>>
>> I just finished my first round of testing with this new
>> version — Env is -
>> VS8 beta 1.
>> ddk 3790.1830
>> wdf 5054.
>>
>> Only thing I had to do ( well of course without reading
>> Mark’s doc thoroughly :slight_smile: is to plug this in sources -
>>
>> WDF_ROOT=C:\WINDDK\WDF\01.00.5054
>>
>>
>>
>> Everything is fine.
>>
>>
>>
>> Thanks Mark !
>>
>>
>>
>> -pro
>>
>> ----- Original Message -----
>> From: “Mark Roddy”
>> To: “Windows System Software Devs Interest List”
>> Sent: Sunday, May 08, 2005 8:59 AM
>> Subject: [ntdev] DDKBUILD Update
>>
>>
>> > DDKBUILD Update.
>> >
>> >
>> > DDKBUILD version 3.12.35 is available for download from
>> > www.hollistech.com.
>> > This minor update adds support for WDF beta 3 kernel mode windows
>> driver
>> > foundation builds (WDF version 5054.)
>> >
>> > The direct link is:
>> > http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>> >
>> > =====================
>> > Mark Roddy
>> > Windows .NET/XP/2000 Consulting
>> > Hollis Technology Solutions 603-321-1032
>> > www.hollistech.com
>> >
>> >
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@garlic.com
>> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>> >
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: unknown lmsubst tag
>> argument: ‘’
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

The way I deal with this is to use a front end that sets the various
environment variables used by visual studio. So for any given instance of
visual studio there is one set of ‘global’ environment variables. The set of
variables in play is generally tied to a specific CVS controlled development
branch. In reality I only work on one development branch at time, and the
time splice is weeks or months, so I have only one set of global variables
in play.

Your suggestion for a command line option for pointing at a specific ddk
location has the problem that each major ddk release has different
variations on how it is invoked, which is why I keep sticking with the
‘target platform specification’ concept instead. Ddkbuild has to know which
ddk flavor it is dealing with, not just where it is located.

=====================
Mark Roddy
Windows .NET/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Sunday, May 08, 2005 4:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DDKBUILD Update

This much I can live with, given that the benifits I get out
of ddkbuild.
And of course, I could have set this in global env. vars, but
I would much rather prefer to drop that one to the cmd line
args for ddk build that I mentioned to Mark couple weeks ago.
To me getting out of workspace and reactivate to get the
latest env. is bit of a work. Sorry Mark, I’m the laziest you
would ever encounter :slight_smile:

BTW, the BSC is even a big bonus.

-pro

----- Original Message -----
From: “Mark Roddy”
> To: “Windows System Software Devs Interest List”
> Sent: Sunday, May 08, 2005 11:56 AM
> Subject: RE: [ntdev] DDKBUILD Update
>
>
> >> Set_wdf_env.cmd does this for you.
> >>
> >> d
> >
> > Well the problem is that ddkbuild has to know where
> “set_wdf_env.cmd” is
> > in
> > order to run it. That problem is solved by requiring that
> WDF_ROOT is set
> > before invoking ddkbuild. A bit circular, but what could I
> do? Anyhow one
> > gets the remainder of set_wdf_env done for you.
> >
> >
> >
> > =====================
> > Mark Roddy
> > Windows .NET/XP/2000 Consulting
> > Hollis Technology Solutions 603-321-1032
> > www.hollistech.com
> >
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
> >> Sent: Sunday, May 08, 2005 2:07 PM
> >> To: Windows System Software Devs Interest List
> >> Subject: RE: [ntdev] DDKBUILD Update
> >>
> >> Set_wdf_env.cmd does this for you.
> >>
> >> d
> >>
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of
> Prokash Sinha
> >> Sent: Sunday, May 08, 2005 9:47 AM
> >> To: Windows System Software Devs Interest List
> >> Subject: Re: [ntdev] DDKBUILD Update
> >>
> >> I just finished my first round of testing with this new
> >> version — Env is -
> >> VS8 beta 1.
> >> ddk 3790.1830
> >> wdf 5054.
> >>
> >> Only thing I had to do ( well of course without reading
> >> Mark’s doc thoroughly :slight_smile: is to plug this in sources -
> >>
> >> WDF_ROOT=C:\WINDDK\WDF\01.00.5054
> >>
> >>
> >>
> >> Everything is fine.
> >>
> >>
> >>
> >> Thanks Mark !
> >>
> >>
> >>
> >> -pro
> >>
> >> ----- Original Message -----
> >> From: “Mark Roddy”
> >> To: “Windows System Software Devs Interest List”
>
> >> Sent: Sunday, May 08, 2005 8:59 AM
> >> Subject: [ntdev] DDKBUILD Update
> >>
> >>
> >> > DDKBUILD Update.
> >> >
> >> >
> >> > DDKBUILD version 3.12.35 is available for download from
> >> > www.hollistech.com.
> >> > This minor update adds support for WDF beta 3 kernel mode windows
> >> driver
> >> > foundation builds (WDF version 5054.)
> >> >
> >> > The direct link is:
> >> > http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
> >> >
> >> > =====================
> >> > Mark Roddy
> >> > Windows .NET/XP/2000 Consulting
> >> > Hollis Technology Solutions 603-321-1032
> >> > www.hollistech.com
> >> >
> >> >
> >> >
> >> >
> >> > —
> >> > Questions? First check the Kernel Driver FAQ at
> >> > http://www.osronline.com/article.cfm?id=256
> >> >
> >> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> >> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >> >
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at
> >> http://www.osronline.com/article.cfm?id=256
> >>
> >> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.com
> >> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at
> >> http://www.osronline.com/article.cfm?id=256
> >>
> >> You are currently subscribed to ntdev as: unknown lmsubst tag
> >> argument: ‘’
> >> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >>
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

> The way I deal with this is to use a front end that sets the various

environment variables used by visual studio. So for any given instance of
visual studio there is one set of ‘global’ environment variables.

Somewhat off topic, but your post reminded me: Anyone know of a good (or at
least reasonably clean and sane) way to get visual studio to deal with
multiple environments at once?

We’ve got a UM project that consists of 20-30 individual apps, dlls, static
libraries, etc. All this witches brew will build with a single click of the
button in VS.

There are also about 25 variations on exactly what it will build, which you
select from the build type dropdown. All this works well enough, except
that some are for x86, some are for ia64, and some are for x8664. So you
have to have three copies of vs open, and somehow remember which is which,
and only select the right build types in each one, or you get one whole pile
of bogus warnings and syntax errors from having the wrong compilers and
linkers for the selected build environment.

Since you have to build and test for all three environments after any source
change, this is a bloody pain.

Can anyone think of a clever way to be able to set all of the tool and
include paths correctly when you select a build type from inside VS? Keep
in mind that they will probably be different on every developer’s machine
(and there are about 50 developers), and will certainly be different in the
main build vmware machine environments.

Thanks,
Loren

Loren Wilton wrote:

>The way I deal with this is to use a front end that sets the various
>environment variables used by visual studio. So for any given instance of
>visual studio there is one set of ‘global’ environment variables.
>
>

Somewhat off topic, but your post reminded me: Anyone know of a good (or at
least reasonably clean and sane) way to get visual studio to deal with
multiple environments at once?

You could add a makefile project to your solution. Something similar to
ddkbuild. Then write a cmd file
that builds all your projects. (perl may be better). You can tell VS to
use only this project to build the solution.
You have to add new projects by hand in this cmd though.

Andrei

We’ve got a UM project that consists of 20-30 individual apps, dlls, static
libraries, etc. All this witches brew will build with a single click of the
button in VS.

There are also about 25 variations on exactly what it will build, which you
select from the build type dropdown. All this works well enough, except
that some are for x86, some are for ia64, and some are for x8664. So you
have to have three copies of vs open, and somehow remember which is which,
and only select the right build types in each one, or you get one whole pile
of bogus warnings and syntax errors from having the wrong compilers and
linkers for the selected build environment.

Since you have to build and test for all three environments after any source
change, this is a bloody pain.

Can anyone think of a clever way to be able to set all of the tool and
include paths correctly when you select a build type from inside VS? Keep
in mind that they will probably be different on every developer’s machine
(and there are about 50 developers), and will certainly be different in the
main build vmware machine environments.

Thanks,
Loren


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@bitdefender.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Ignorance more frequently begets confidence than does knowledge.
— Charles Darwin


This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/

But …

You cannot build \WinDDK\WDF\Samples in either DDK or a Microsoft build
environment. At least I haven’t been able to.


The personal opinion of
Gary G. Little

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> DDKBUILD Update.
>
>
> DDKBUILD version 3.12.35 is available for download from
> www.hollistech.com.
> This minor update adds support for WDF beta 3 kernel mode windows driver
> foundation builds (WDF version 5054.)
>
> The direct link is:
> http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>
>
>

You should take that complaint to the WDF beta site where it could be
discussed in more detail. The current WDF beta (3 - build 5054) builds just
fine on my systems.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, May 09, 2005 10:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKBUILD Update

But …

You cannot build \WinDDK\WDF\Samples in either DDK or a Microsoft build
environment. At least I haven’t been able to.


The personal opinion of
Gary G. Little

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> DDKBUILD Update.
>
>
> DDKBUILD version 3.12.35 is available for download from
> www.hollistech.com.
> This minor update adds support for WDF beta 3 kernel mode windows
> driver foundation builds (WDF version 5054.)
>
> The direct link is:
> http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032 www.hollistech.com
>
>
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Winddk\wdf\samples is very ancient, as indicated by the date (4/14/04).
You need to install the latest bits and then compile the latest samples.
The samples from a year ago will no longer compile. For instance, the
message your copied here about WDFSTATUS being an unknown type is one of
the changes made over the past year (it used to be defined, now we use
plain old NTSTATUS).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, May 09, 2005 8:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKBUILD Update

You should take that complaint to the WDF beta site where it could be
discussed in more detail. The current WDF beta (3 - build 5054) builds
just
fine on my systems.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, May 09, 2005 10:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKBUILD Update

But …

You cannot build \WinDDK\WDF\Samples in either DDK or a Microsoft build
environment. At least I haven’t been able to.


The personal opinion of
Gary G. Little

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> DDKBUILD Update.
>
>
> DDKBUILD version 3.12.35 is available for download from
> www.hollistech.com.
> This minor update adds support for WDF beta 3 kernel mode windows
> driver foundation builds (WDF version 5054.)
>
> The direct link is:
> http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032 www.hollistech.com
>
>
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

There lies the rub. Not all of the WDF\SAMPLES have been ported into the
5054 build. Which means if what you are working is best exampled in
WDF/SAMPLES, you are up a creek with a very smelly paddle in your hands. Why
was fileio not included in the 5054 build?


The personal opinion of
Gary G. Little

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Winddk\wdf\samples is very ancient, as indicated by the date (4/14/04).
You need to install the latest bits and then compile the latest samples.
The samples from a year ago will no longer compile. For instance, the
message your copied here about WDFSTATUS being an unknown type is one of
the changes made over the past year (it used to be defined, now we use
plain old NTSTATUS).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, May 09, 2005 8:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKBUILD Update

You should take that complaint to the WDF beta site where it could be
discussed in more detail. The current WDF beta (3 - build 5054) builds
just
fine on my systems.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, May 09, 2005 10:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKBUILD Update

But …

You cannot build \WinDDK\WDF\Samples in either DDK or a Microsoft build
environment. At least I haven’t been able to.


The personal opinion of
Gary G. Little

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> DDKBUILD Update.
>
>
> DDKBUILD version 3.12.35 is available for download from
> www.hollistech.com.
> This minor update adds support for WDF beta 3 kernel mode windows
> driver foundation builds (WDF version 5054.)
>
> The direct link is:
> http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032 www.hollistech.com
>
>
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The fileio samples was renamed to nonpnp, so the sample is still there
:). You can use sourcesrename.cmd from the previous beta drop to update
a sample if you really need to.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, May 09, 2005 10:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKBUILD Update

There lies the rub. Not all of the WDF\SAMPLES have been ported into the

5054 build. Which means if what you are working is best exampled in
WDF/SAMPLES, you are up a creek with a very smelly paddle in your hands.
Why
was fileio not included in the 5054 build?


The personal opinion of
Gary G. Little

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Winddk\wdf\samples is very ancient, as indicated by the date (4/14/04).
You need to install the latest bits and then compile the latest samples.
The samples from a year ago will no longer compile. For instance, the
message your copied here about WDFSTATUS being an unknown type is one of
the changes made over the past year (it used to be defined, now we use
plain old NTSTATUS).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, May 09, 2005 8:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKBUILD Update

You should take that complaint to the WDF beta site where it could be
discussed in more detail. The current WDF beta (3 - build 5054) builds
just
fine on my systems.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, May 09, 2005 10:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKBUILD Update

But …

You cannot build \WinDDK\WDF\Samples in either DDK or a Microsoft build
environment. At least I haven’t been able to.


The personal opinion of
Gary G. Little

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> DDKBUILD Update.
>
>
> DDKBUILD version 3.12.35 is available for download from
> www.hollistech.com.
> This minor update adds support for WDF beta 3 kernel mode windows
> driver foundation builds (WDF version 5054.)
>
> The direct link is:
> http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032 www.hollistech.com
>
>
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Okie dokie … Thanks.


The personal opinion of
Gary G. Little

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The fileio samples was renamed to nonpnp, so the sample is still there
:). You can use sourcesrename.cmd from the previous beta drop to update
a sample if you really need to.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, May 09, 2005 10:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKBUILD Update

There lies the rub. Not all of the WDF\SAMPLES have been ported into the

5054 build. Which means if what you are working is best exampled in
WDF/SAMPLES, you are up a creek with a very smelly paddle in your hands.
Why
was fileio not included in the 5054 build?


The personal opinion of
Gary G. Little

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Winddk\wdf\samples is very ancient, as indicated by the date (4/14/04).
You need to install the latest bits and then compile the latest samples.
The samples from a year ago will no longer compile. For instance, the
message your copied here about WDFSTATUS being an unknown type is one of
the changes made over the past year (it used to be defined, now we use
plain old NTSTATUS).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, May 09, 2005 8:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKBUILD Update

You should take that complaint to the WDF beta site where it could be
discussed in more detail. The current WDF beta (3 - build 5054) builds
just
fine on my systems.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, May 09, 2005 10:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKBUILD Update

But …

You cannot build \WinDDK\WDF\Samples in either DDK or a Microsoft build
environment. At least I haven’t been able to.


The personal opinion of
Gary G. Little

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> DDKBUILD Update.
>
>
> DDKBUILD version 3.12.35 is available for download from
> www.hollistech.com.
> This minor update adds support for WDF beta 3 kernel mode windows
> driver foundation builds (WDF version 5054.)
>
> The direct link is:
> http://www.hollistech.com/Resources/ddkbuild/ddkbuild3_12.zip
>
> =====================
> Mark Roddy
> Windows .NET/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032 www.hollistech.com
>
>
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

With such a project complexity, I would move to BUILD and command-line
builds.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Loren Wilton”
To: “Windows System Software Devs Interest List”
Sent: Monday, May 09, 2005 12:15 PM
Subject: Re: [ntdev] DDKBUILD Update

> > The way I deal with this is to use a front end that sets the various
> > environment variables used by visual studio. So for any given instance of
> > visual studio there is one set of ‘global’ environment variables.
>
> Somewhat off topic, but your post reminded me: Anyone know of a good (or at
> least reasonably clean and sane) way to get visual studio to deal with
> multiple environments at once?
>
> We’ve got a UM project that consists of 20-30 individual apps, dlls, static
> libraries, etc. All this witches brew will build with a single click of the
> button in VS.
>
> There are also about 25 variations on exactly what it will build, which you
> select from the build type dropdown. All this works well enough, except
> that some are for x86, some are for ia64, and some are for x8664. So you
> have to have three copies of vs open, and somehow remember which is which,
> and only select the right build types in each one, or you get one whole pile
> of bogus warnings and syntax errors from having the wrong compilers and
> linkers for the selected build environment.
>
> Since you have to build and test for all three environments after any source
> change, this is a bloody pain.
>
> Can anyone think of a clever way to be able to set all of the tool and
> include paths correctly when you select a build type from inside VS? Keep
> in mind that they will probably be different on every developer’s machine
> (and there are about 50 developers), and will certainly be different in the
> main build vmware machine environments.
>
> Thanks,
> Loren
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

After years of working with projects having hundreds of
thousands of lines of code, I’d use MSVC.NET pronto and presto.
All the required functionality is there, from the Configuration
Manager to the Macro Generator and Addin processor. Worse comes
to worse, you can easily implement a build button (through an
Addin) to revert to the dark ages, if that’s what you really
feel like!

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”

Sent: Monday, May 09, 2005 6:29 PM
Subject: Re: [ntdev] DDKBUILD Update

> With such a project complexity, I would move to BUILD and
> command-line
> builds.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Loren Wilton”
> To: “Windows System Software Devs Interest List”
>
> Sent: Monday, May 09, 2005 12:15 PM
> Subject: Re: [ntdev] DDKBUILD Update
>
>
>> > The way I deal with this is to use a front end that sets
>> > the various
>> > environment variables used by visual studio. So for any
>> > given instance of
>> > visual studio there is one set of ‘global’ environment
>> > variables.
>>
>> Somewhat off topic, but your post reminded me: Anyone know
>> of a good (or at
>> least reasonably clean and sane) way to get visual studio to
>> deal with
>> multiple environments at once?
>>
>> We’ve got a UM project that consists of 20-30 individual
>> apps, dlls, static
>> libraries, etc. All this witches brew will build with a
>> single click of the
>> button in VS.
>>
>> There are also about 25 variations on exactly what it will
>> build, which you
>> select from the build type dropdown. All this works well
>> enough, except
>> that some are for x86, some are for ia64, and some are for
>> x8664. So you
>> have to have three copies of vs open, and somehow remember
>> which is which,
>> and only select the right build types in each one, or you get
>> one whole pile
>> of bogus warnings and syntax errors from having the wrong
>> compilers and
>> linkers for the selected build environment.
>>
>> Since you have to build and test for all three environments
>> after any source
>> change, this is a bloody pain.
>>
>> Can anyone think of a clever way to be able to set all of the
>> tool and
>> include paths correctly when you select a build type from
>> inside VS? Keep
>> in mind that they will probably be different on every
>> developer’s machine
>> (and there are about 50 developers), and will certainly be
>> different in the
>> main build vmware machine environments.
>>
>> Thanks,
>> Loren
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@storagecraft.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

With MSVC 6 builds, the project containing 10 binaries require a dedicated
position of the build engineer.
Not so with BUILD.

Building from IDE gives no advantages, except being more comprehendable for
novices who are eager to build the 1-message-box demo apps. All really serious
software - from the Windows kernel/core OS to all major open source titles - is
built from the command line.

That’s why MS moved to MSBuild, and uses it also as an underlying build
engine in modern MSVCs. At least no more idiotic DSP files, XML files with
documented syntax instead. You can, for instance, copy-paste the parts of them.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, May 10, 2005 6:57 AM
Subject: Re: [ntdev] DDKBUILD Update

> After years of working with projects having hundreds of
> thousands of lines of code, I’d use MSVC.NET pronto and presto.
> All the required functionality is there, from the Configuration
> Manager to the Macro Generator and Addin processor. Worse comes
> to worse, you can easily implement a build button (through an
> Addin) to revert to the dark ages, if that’s what you really
> feel like!
>
> Alberto.
>
> ----- Original Message -----
> From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
>
> Sent: Monday, May 09, 2005 6:29 PM
> Subject: Re: [ntdev] DDKBUILD Update
>
>
> > With such a project complexity, I would move to BUILD and
> > command-line
> > builds.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > ----- Original Message -----
> > From: “Loren Wilton”
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Monday, May 09, 2005 12:15 PM
> > Subject: Re: [ntdev] DDKBUILD Update
> >
> >
> >> > The way I deal with this is to use a front end that sets
> >> > the various
> >> > environment variables used by visual studio. So for any
> >> > given instance of
> >> > visual studio there is one set of ‘global’ environment
> >> > variables.
> >>
> >> Somewhat off topic, but your post reminded me: Anyone know
> >> of a good (or at
> >> least reasonably clean and sane) way to get visual studio to
> >> deal with
> >> multiple environments at once?
> >>
> >> We’ve got a UM project that consists of 20-30 individual
> >> apps, dlls, static
> >> libraries, etc. All this witches brew will build with a
> >> single click of the
> >> button in VS.
> >>
> >> There are also about 25 variations on exactly what it will
> >> build, which you
> >> select from the build type dropdown. All this works well
> >> enough, except
> >> that some are for x86, some are for ia64, and some are for
> >> x8664. So you
> >> have to have three copies of vs open, and somehow remember
> >> which is which,
> >> and only select the right build types in each one, or you get
> >> one whole pile
> >> of bogus warnings and syntax errors from having the wrong
> >> compilers and
> >> linkers for the selected build environment.
> >>
> >> Since you have to build and test for all three environments
> >> after any source
> >> change, this is a bloody pain.
> >>
> >> Can anyone think of a clever way to be able to set all of the
> >> tool and
> >> include paths correctly when you select a build type from
> >> inside VS? Keep
> >> in mind that they will probably be different on every
> >> developer’s machine
> >> (and there are about 50 developers), and will certainly be
> >> different in the
> >> main build vmware machine environments.
> >>
> >> Thanks,
> >> Loren
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >>
> >> You are currently subscribed to ntdev as:
> >> xxxxx@storagecraft.com
> >> To unsubscribe send a blank email to
> >> xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Put it this way: I’m no novice and I’d use the IDE anytime over
build.exe.

With 10 binaries you can set up one or more projects, set up the
dependencies, done: double click on the .dsw or .sln and it
builds. No need for a release engineer. Everything’s included in
the dsw file, and you can tell your release engineer to invoke
it through a cl.exe command line for production builds. The dsp
files might as well be opaque, and what do you know, XML
documentation can be a real help if the programmer uses it
right!

In fact, with 10 binaries you might as well just compile them
every time, it takes less than 30 seconds on a modern machine.
Why bother with makefiles, sources files, and all the associated
paraphernalia ? Just write yourself a .bat file, say, “go.bat”,
type “go”, press enter, done. Takes less time than writing a
makefile or a sources file. But that’s not feasible for larger
projects, right ?

With the IDE, you can have multiple configurations through the
Config Manager. You can have different settings per
configuration. You can link projects through dependency chains.
You can subsume components from remote machines as an integral
part of your project, workspace or solution. You can compile and
test (even a driver!) from inside the IDE. You can set up your
paths on a workspace basis. You can add your own macros and
addins to the build process. You can change your compile and
link options through the IDE. You have automatic integration
with your source control system. You can add your own tools to
the environment by using VSIP. You have real-time, automatic,
on-the-spot, help.

The bigger my project gets, the more efficient it becomes to
build it with the IDE, because of the extensive configuration
management features included within. Also, if I use the IDE
right, it’s all interconnected and I don’t need to leave that
window: click the build button, click the debug button or press
F5, set breakpoints, single step, everything is done on the IDE.
No need to keep bouncing around between windows or bother about
whether software package x, y or z is installed or it is
correctly working: it’s all reachable from the IDE through
toolbars or through the tools menu. Writing and testing a
driver, mind you, becomes as easy as writing an application.

This is particularly important when you have multiple
directories: you can bury the directory structure inside the
structure of your workspace or of your solution, and you can use
the IDE browser to your advantage. Moreover, not to open another
can of worms, you can drive much of your development through the
Class view, no more need to bother about files either.

And again, hey, if you’re addicted to build.exe, just include it
as a post-build step. It’s that easy!

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”

Sent: Tuesday, May 10, 2005 8:47 AM
Subject: Re: [ntdev] DDKBUILD Update

> With MSVC 6 builds, the project containing 10 binaries
> require a dedicated
> position of the build engineer.
> Not so with BUILD.
>
> Building from IDE gives no advantages, except being more
> comprehendable for
> novices who are eager to build the 1-message-box demo apps.
> All really serious
> software - from the Windows kernel/core OS to all major open
> source titles - is
> built from the command line.
>
> That’s why MS moved to MSBuild, and uses it also as an
> underlying build
> engine in modern MSVCs. At least no more idiotic DSP files,
> XML files with
> documented syntax instead. You can, for instance, copy-paste
> the parts of them.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Alberto Moreira”
> To: “Windows System Software Devs Interest List”
>
> Sent: Tuesday, May 10, 2005 6:57 AM
> Subject: Re: [ntdev] DDKBUILD Update
>
>
>> After years of working with projects having hundreds of
>> thousands of lines of code, I’d use MSVC.NET pronto and
>> presto.
>> All the required functionality is there, from the
>> Configuration
>> Manager to the Macro Generator and Addin processor. Worse
>> comes
>> to worse, you can easily implement a build button (through an
>> Addin) to revert to the dark ages, if that’s what you really
>> feel like!
>>
>> Alberto.
>>
>> ----- Original Message -----
>> From: “Maxim S. Shatskih”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Monday, May 09, 2005 6:29 PM
>> Subject: Re: [ntdev] DDKBUILD Update
>>
>>
>> > With such a project complexity, I would move to BUILD
>> > and
>> > command-line
>> > builds.
>> >
>> > Maxim Shatskih, Windows DDK MVP
>> > StorageCraft Corporation
>> > xxxxx@storagecraft.com
>> > http://www.storagecraft.com
>> >
>> > ----- Original Message -----
>> > From: “Loren Wilton”
>> > To: “Windows System Software Devs Interest List”
>> >
>> > Sent: Monday, May 09, 2005 12:15 PM
>> > Subject: Re: [ntdev] DDKBUILD Update
>> >
>> >
>> >> > The way I deal with this is to use a front end that sets
>> >> > the various
>> >> > environment variables used by visual studio. So for any
>> >> > given instance of
>> >> > visual studio there is one set of ‘global’ environment
>> >> > variables.
>> >>
>> >> Somewhat off topic, but your post reminded me: Anyone
>> >> know
>> >> of a good (or at
>> >> least reasonably clean and sane) way to get visual studio
>> >> to
>> >> deal with
>> >> multiple environments at once?
>> >>
>> >> We’ve got a UM project that consists of 20-30 individual
>> >> apps, dlls, static
>> >> libraries, etc. All this witches brew will build with a
>> >> single click of the
>> >> button in VS.
>> >>
>> >> There are also about 25 variations on exactly what it will
>> >> build, which you
>> >> select from the build type dropdown. All this works well
>> >> enough, except
>> >> that some are for x86, some are for ia64, and some are for
>> >> x8664. So you
>> >> have to have three copies of vs open, and somehow remember
>> >> which is which,
>> >> and only select the right build types in each one, or you
>> >> get
>> >> one whole pile
>> >> of bogus warnings and syntax errors from having the wrong
>> >> compilers and
>> >> linkers for the selected build environment.
>> >>
>> >> Since you have to build and test for all three
>> >> environments
>> >> after any source
>> >> change, this is a bloody pain.
>> >>
>> >> Can anyone think of a clever way to be able to set all of
>> >> the
>> >> tool and
>> >> include paths correctly when you select a build type from
>> >> inside VS? Keep
>> >> in mind that they will probably be different on every
>> >> developer’s machine
>> >> (and there are about 50 developers), and will certainly be
>> >> different in the
>> >> main build vmware machine environments.
>> >>
>> >> Thanks,
>> >> Loren
>> >>
>> >>
>> >> —
>> >> Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >>
>> >> You are currently subscribed to ntdev as:
>> >> xxxxx@storagecraft.com
>> >> To unsubscribe send a blank email to
>> >> xxxxx@lists.osr.com
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@ieee.org
>> > To unsubscribe send a blank email to
>> > xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@storagecraft.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

> And again, hey, if you’re addicted to build.exe, just include it

as a post-build step. It’s that easy!

Alberto, below is the real-world example of using IDE for builds. Saw this in
my previous employer’s company. The project is - COM/C++/ATL/MFC client-server
app working with an SQL database, the server logic and the client UI, including
the shell extensions.

Typical scenario of build engineer’s work with IDE builds:

  • Get Latest Version of everything. It usually works fine.

  • opening the DSW file. It spits several warnings about some missing files,
    since it saves the absolute pathnames of the files opened in editor windows,
    and absolute pathnames differ from machine to machine and from personal
    preferences to personal preferences. OK, lets ignore this irritating stuff.

  • pressing the BUILD button. An error about one more absolute pathname. Fixing
    it is a PITA. The SCC files are locked by the developer, and the build engineer
    cannot modify them. The easiest way for a build engineer is to re-create the
    same absolute pathnames as the developer used.

  • OK, this conflicts with the custom pathnames created by another developer.
    One more PITA. The build engineer manually removes the Read-Only attribute from
    a DSP file and patches the pathnames in it, ignoring the “DO NOT EDIT!” banner.
    Very good that MS did not make it binary :slight_smile: well, MS is a smarter company then
    some PowerSoft or such (they used binary project files in PowerBuilder - the
    worst development tool ever made).

  • OK, now the next issue. The IDE allows you to customize main INCLUDE path.
    Great. Some “smart” developer was trying to use this Great Fashionable New
    Feature. Again the thing is unbuildable on the build engineer’s machine.
    Again - removing the R/O flag from the file in Explorer, then patching the
    paths.

  • well, now no pathname errors! very great! OK, now some compile errors -
    something is not defined. For instance, “_mainCRTStartup” is not defined or
    something like. How great! The build engineer starts the bothering search
    process over the MS’s KB, and discovered that the developer set the
    _ATL_MIN_CRT in the Debug config of the project via the fancy GUI, and forgot
    to do this in Release! Wow! It is not Debug/Release! It is 8 configs!
    Debug/Release, MinSize/MinDependency, ANSI/Unicode. So, please open the DSP
    file in Notepad (it cannot be loaded to MSVC’s text editor - it interprets it
    as a project and not as a text file) and patch the defines.

  • build engineer cannot check-in any changes, and the developers are already
    gone - it is too late. So, the build engineer writes emails to the developers
    to fix the build, stop using absolute pathnames, stop using customized
    pathnames, be consistent in using macros etc. Some developer forget about this,
    and the next build also has issues.

Now imagine you have a source customer. You will have lots of time lots
explaining him how to build such a project. With command-line builds, all is
simple - “install DDK version XX, then install Platform SDK, then start the
build env and say build -c”.

With BUILD, you have:

  • predictable build environment - if it works on one person’s machine, it will
    work on any erson’s machine, just install the DDK. No customized pathnames. No
    absolute pathnames at all! they are just not allowed!
  • project setting files easy to review, most are 1 screenful of text. No need
    to do mouse clicks in deeply-buried build option controls in the IDE dialog.
    There is nothing more ergonomic then a text file.
  • Copy/Paste of settings from one project to another.
  • ability of central control of build settings over the whole team (by
    !INCLUDE).
  • ability to write any manual comments in the project options file.
  • any possibly build configs by #ifdefs in the code and a set of macros in the
    text file, some being commented away. Text file in an editor is by far better
    then a pathetic short single-line control of “Preprocessor Directives” in the
    IDE, which also does not allow to comment-away some macros.
  • ability to integrate literally ANY pre- and post- build procedures by writing
    MAKEFILE from scratch (instead of using MAKEFILE.DEF). MAKEFILE is by far more
    generic then the “Post Build Step” feature of the IDE.
  • build options are not hidden under any fancy wrappers, but exactly exposed to
    the developer or build engineer.

That’s why MS builds the OS using BUILD (and I believe other products too).
That’s why IDEs are not popular in open-source world.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

The more complex the project, the less useful the IDE is for managing it.

Here’s an example:

Add a file to the project, change the settings on the file so that it’s
unique (preprocessor defines, optimization settings, etc.). Oops, now I
have to do the same thing again because I forgot to select multiple
configurations. Oh, but I can’t select all of them, because I don’t want
to duplicate the optimization settings between Release and Debug configs…
Now add another file to the project, and duplicate the settings on the
first file. Oh bother, back and forth, check this setting on file1, set it
on file2, check that setting on file1, set it on file2.

With a text file of whatever flavor, I have to do a bit more work up front
to decompose the logical groupings of files and settings, but once I’ve
done that, adding another file with the same settings as the first is a one
line addition to the file group definition I care about.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

“Alberto Moreira”
g> To
Sent by: “Windows System Software Devs
bounce-208752-643 Interest List”
xxxxx@lists.osr.com
No Phone Info cc
Available
Subject
Re: [ntdev] DDKBUILD Update
05/10/2005 07:30
AM

Please respond to
“Windows System
Software Devs
Interest List”
com>

Put it this way: I’m no novice and I’d use the IDE anytime over
build.exe.

With 10 binaries you can set up one or more projects, set up the
dependencies, done: double click on the .dsw or .sln and it
builds. No need for a release engineer. Everything’s included in
the dsw file, and you can tell your release engineer to invoke
it through a cl.exe command line for production builds. The dsp
files might as well be opaque, and what do you know, XML
documentation can be a real help if the programmer uses it
right!

In fact, with 10 binaries you might as well just compile them
every time, it takes less than 30 seconds on a modern machine.
Why bother with makefiles, sources files, and all the associated
paraphernalia ? Just write yourself a .bat file, say, “go.bat”,
type “go”, press enter, done. Takes less time than writing a
makefile or a sources file. But that’s not feasible for larger
projects, right ?

With the IDE, you can have multiple configurations through the
Config Manager. You can have different settings per
configuration. You can link projects through dependency chains.
You can subsume components from remote machines as an integral
part of your project, workspace or solution. You can compile and
test (even a driver!) from inside the IDE. You can set up your
paths on a workspace basis. You can add your own macros and
addins to the build process. You can change your compile and
link options through the IDE. You have automatic integration
with your source control system. You can add your own tools to
the environment by using VSIP. You have real-time, automatic,
on-the-spot, help.

The bigger my project gets, the more efficient it becomes to
build it with the IDE, because of the extensive configuration
management features included within. Also, if I use the IDE
right, it’s all interconnected and I don’t need to leave that
window: click the build button, click the debug button or press
F5, set breakpoints, single step, everything is done on the IDE.
No need to keep bouncing around between windows or bother about
whether software package x, y or z is installed or it is
correctly working: it’s all reachable from the IDE through
toolbars or through the tools menu. Writing and testing a
driver, mind you, becomes as easy as writing an application.

This is particularly important when you have multiple
directories: you can bury the directory structure inside the
structure of your workspace or of your solution, and you can use
the IDE browser to your advantage. Moreover, not to open another
can of worms, you can drive much of your development through the
Class view, no more need to bother about files either.

And again, hey, if you’re addicted to build.exe, just include it
as a post-build step. It’s that easy!

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”

Sent: Tuesday, May 10, 2005 8:47 AM
Subject: Re: [ntdev] DDKBUILD Update

> With MSVC 6 builds, the project containing 10 binaries
> require a dedicated
> position of the build engineer.
> Not so with BUILD.
>
> Building from IDE gives no advantages, except being more
> comprehendable for
> novices who are eager to build the 1-message-box demo apps.
> All really serious
> software - from the Windows kernel/core OS to all major open
> source titles - is
> built from the command line.
>
> That’s why MS moved to MSBuild, and uses it also as an
> underlying build
> engine in modern MSVCs. At least no more idiotic DSP files,
> XML files with
> documented syntax instead. You can, for instance, copy-paste
> the parts of them.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Alberto Moreira”
> To: “Windows System Software Devs Interest List”
>
> Sent: Tuesday, May 10, 2005 6:57 AM
> Subject: Re: [ntdev] DDKBUILD Update
>
>
>> After years of working with projects having hundreds of
>> thousands of lines of code, I’d use MSVC.NET pronto and
>> presto.
>> All the required functionality is there, from the
>> Configuration
>> Manager to the Macro Generator and Addin processor. Worse
>> comes
>> to worse, you can easily implement a build button (through an
>> Addin) to revert to the dark ages, if that’s what you really
>> feel like!
>>
>> Alberto.
>>
>> ----- Original Message -----
>> From: “Maxim S. Shatskih”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Monday, May 09, 2005 6:29 PM
>> Subject: Re: [ntdev] DDKBUILD Update
>>
>>
>> > With such a project complexity, I would move to BUILD
>> > and
>> > command-line
>> > builds.
>> >
>> > Maxim Shatskih, Windows DDK MVP
>> > StorageCraft Corporation
>> > xxxxx@storagecraft.com
>> > http://www.storagecraft.com
>> >
>> > ----- Original Message -----
>> > From: “Loren Wilton”
>> > To: “Windows System Software Devs Interest List”
>> >
>> > Sent: Monday, May 09, 2005 12:15 PM
>> > Subject: Re: [ntdev] DDKBUILD Update
>> >
>> >
>> >> > The way I deal with this is to use a front end that sets
>> >> > the various
>> >> > environment variables used by visual studio. So for any
>> >> > given instance of
>> >> > visual studio there is one set of ‘global’ environment
>> >> > variables.
>> >>
>> >> Somewhat off topic, but your post reminded me: Anyone
>> >> know
>> >> of a good (or at
>> >> least reasonably clean and sane) way to get visual studio
>> >> to
>> >> deal with
>> >> multiple environments at once?
>> >>
>> >> We’ve got a UM project that consists of 20-30 individual
>> >> apps, dlls, static
>> >> libraries, etc. All this witches brew will build with a
>> >> single click of the
>> >> button in VS.
>> >>
>> >> There are also about 25 variations on exactly what it will
>> >> build, which you
>> >> select from the build type dropdown. All this works well
>> >> enough, except
>> >> that some are for x86, some are for ia64, and some are for
>> >> x8664. So you
>> >> have to have three copies of vs open, and somehow remember
>> >> which is which,
>> >> and only select the right build types in each one, or you
>> >> get
>> >> one whole pile
>> >> of bogus warnings and syntax errors from having the wrong
>> >> compilers and
>> >> linkers for the selected build environment.
>> >>
>> >> Since you have to build and test for all three
>> >> environments
>> >> after any source
>> >> change, this is a bloody pain.
>> >>
>> >> Can anyone think of a clever way to be able to set all of
>> >> the
>> >> tool and
>> >> include paths correctly when you select a build type from
>> >> inside VS? Keep
>> >> in mind that they will probably be different on every
>> >> developer’s machine
>> >> (and there are about 50 developers), and will certainly be
>> >> different in the
>> >> main build vmware machine environments.
>> >>
>> >> Thanks,
>> >> Loren
>> >>
>> >>
>> >> —
>> >> Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >>
>> >> You are currently subscribed to ntdev as:
>> >> xxxxx@storagecraft.com
>> >> To unsubscribe send a blank email to
>> >> xxxxx@lists.osr.com
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@ieee.org
>> > To unsubscribe send a blank email to
>> > xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@storagecraft.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com