Noob Question (Ignore if the question insults)

NTDEV
1

Dear All

I have thought more than once before posting this question ,
considering that the people of the list are fairly technical , but I just
want to let you know that I have tried many things before posting here , so
I googled , read the WDK documentation (well not all of it) .

I have downloaded the latest WDK (includes support for windows server 2008)
and all I want to do is just compile one sample in VC 6 , any sample . After
reading a bit I came across DDKbuild , but it doesn’t support the latest WDK
.

I changed the library files , include files , and executable files in the VC
environment to include the WDK ones. In the project settings I also changed
prompted the project to ignore all default libraries under Link .

Can anyone please help or maybe refer me to any resources to read , I would
really appreciate that .

Regards

AZ

2

> I have downloaded the latest WDK (includes support for windows server 2008)

and all I want to do is just compile one sample in VC 6 , any sample .

Just plain not supported. Use the WDK’s build environment.

For such kind of development, MSVC IDE is text editor only.

DDKBUILD is a proper tool, but, if you have hardships setting it up, then use
the command-line window with BUILD tool. Plain and simple.

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

3

First as has been said many times on this forum there is trying to build a
driver with anything but the WDK is a really bad idea. Second, why do you
believe the DDKbuild does not support the latest WDK? I use the one from
Mark Roddy, and while Microsoft broke things by changing the arguments on
setenv.bat this only breaks x64 and is easily fixable.

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

“Ahmed Zaki” wrote in message news:xxxxx@ntdev…
> Dear All
>
> I have thought more than once before posting this question
> ,
> considering that the people of the list are fairly technical , but I just
> want to let you know that I have tried many things before posting here ,
> so
> I googled , read the WDK documentation (well not all of it) .
>
> I have downloaded the latest WDK (includes support for windows server
> 2008)
> and all I want to do is just compile one sample in VC 6 , any sample .
> After
> reading a bit I came across DDKbuild , but it doesn’t support the latest
> WDK
> .
>
> I changed the library files , include files , and executable files in the
> VC
> environment to include the WDK ones. In the project settings I also
> changed
> prompted the project to ignore all default libraries under Link .
>
> Can anyone please help or maybe refer me to any resources to read , I
> would
> really appreciate that .
>
>
>
> Regards
>
> AZ
>
>

4

> have tried many things before posting here , so I googled ,

Look - this issue has been discussed in this NG (as well as in MSFT one) countless number of times. Therefore, I can hardly believe that Google did not point you to some thread where it had been stated that building Windows driver with anything, apart from WDK, is really bad idea. Therefore, I suspect you just decided that you want to build a driver with VC, no matter what, and ignored the rest completely…

Anton Bassov

5

I’ll have an update for the inexplicable and inconsistent change from amd64
to x64 shortly. As Don noted, this is easy enough to fix up in the bat
script yourself.

On Thu, Feb 14, 2008 at 3:46 PM, Don Burn wrote:

> First as has been said many times on this forum there is trying to build a
> driver with anything but the WDK is a really bad idea. Second, why do you
> believe the DDKbuild does not support the latest WDK? I use the one from
> Mark Roddy, and while Microsoft broke things by changing the arguments on
> setenv.bat this only breaks x64 and is easily fixable.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
> “Ahmed Zaki” wrote in message news:xxxxx@ntdev…
> > Dear All
> >
> > I have thought more than once before posting this
> question
> > ,
> > considering that the people of the list are fairly technical , but I
> just
> > want to let you know that I have tried many things before posting here ,
> > so
> > I googled , read the WDK documentation (well not all of it) .
> >
> > I have downloaded the latest WDK (includes support for windows server
> > 2008)
> > and all I want to do is just compile one sample in VC 6 , any sample .
> > After
> > reading a bit I came across DDKbuild , but it doesn’t support the latest
> > WDK
> > .
> >
> > I changed the library files , include files , and executable files in
> the
> > VC
> > environment to include the WDK ones. In the project settings I also
> > changed
> > prompted the project to ignore all default libraries under Link .
> >
> > Can anyone please help or maybe refer me to any resources to read , I
> > would
> > really appreciate that .
> >
> >
> >
> > Regards
> >
> > AZ
> >
> >
>
>
>
> —
> 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
>

–
Mark Roddy

6

DDKBUILD is the way to go.
Just use DDKBUILD to invoke the build the same way you would from the command line. There is no reason to use VC6 to build the driver. Use VC6 build command to run ddkbuild.
Have been able to build the sample driver from the DDK command line?

7

While I have no knowledge that this is the case, I would GUESS that explication for the change is almost certainly that Intel objected to the use of their competitor’s moniker in the build environment.

Believe it or not, I have known some Intel folks to be very touchy about the “AMD64” designation for any x64 Windows build.

Peter
OSR

8

Intel touchy? That’s really surprising, because on matters like what
requires an NDA, and who qualifies for it, they are do darn reasonable
:wink: Personally, I think that they are overstepping the bounds of decency
here, as Microsoft is already giving them a handout in the form of be
willing to include the Itanium in the WDK build environment. I suppose
that one could argue that it is wishful thinking on the part of
Microsoft, as they made the Itanic Mistake. Either way, AMD did do it
first. I wonder how they would feel about renaming the i386 environment
‘x86_32’ or maybe something involving ‘Cyrix.’

mm

xxxxx@osr.com wrote:

While I have no knowledge that this is the case, I would GUESS that explication for the change is almost certainly that Intel objected to the use of their competitor’s moniker in the build environment.

Believe it or not, I have known some Intel folks to be very touchy about the “AMD64” designation for any x64 Windows build.

Peter
OSR

9

That’s funny :slight_smile: I can believe they’re touchy because AMD was real winner
in this case. Competition works. Anyway, it is usually marketing who
believes such things are important.

On the other hand, it is pure MS decision how to name their build
environment. We use x86 and x64 for in our buildengine since 64-bit
build was added. It is shorter, regular and everybody including
customers understands it.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Friday, February 15, 2008 2:26 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Noob Question (Ignore if the question insults)

Intel touchy? That’s really surprising, because on matters
like what requires an NDA, and who qualifies for it, they are
do darn reasonable
:wink: Personally, I think that they are overstepping the bounds
of decency here, as Microsoft is already giving them a
handout in the form of be willing to include the Itanium in
the WDK build environment. I suppose that one could argue
that it is wishful thinking on the part of Microsoft, as they
made the Itanic Mistake. Either way, AMD did do it first. I
wonder how they would feel about renaming the i386
environment ‘x86_32’ or maybe something involving ‘Cyrix.’

mm

xxxxx@osr.com wrote:
> [quote]
> I’ll have an update for the inexplicable and inconsistent
change from
> amd64 to x64 shortly [/quote]
>
> While I have no knowledge that this is the case, I would
GUESS that explication for the change is almost certainly
that Intel objected to the use of their competitor’s moniker
in the build environment.
>
> Believe it or not, I have known some Intel folks to be very
touchy about the “AMD64” designation for any x64 Windows build.
>
> 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

10

And yet it seems the marchitects only partially succeeded since it would appear that everywhere *except* the SETENV arguments still refer/use amd64. So such a petty and useless move without maintaining backward compatibility by keeping amd64 as a valid SETENV flag results in just aggravation. Now all of those build scripts that could use a single token (amd64) to drive their behavior have to pick and chose by context when to use amd64 and x64. Noting of course the $(AMD64) still persists as is, $(TARGET_DIRECTORY) remains amd64, etc. etc. etc. That is a awfully thin bit if paint to apply. Can we expect that next the INF syntax will change, that all the build environment will no longer define _AMD64?

Would it have been such a huge problem if the DDK Team had added x64 to make the market whiners happy and kept amd64 so we could have a simple (aka, no work, no fuss, no mess) transition to the new WDK from the perfectly fine previous version?

As if the population of the planet that uses the DDK will really be swayed by this clever bit of eradication of AMD from the SETENV arguments and somehow conveniently forget that we need to have ‘that other CPU family’ in the stable for testing too.

I am so glad tomorrow is Friday. It’s time for my medication.
-dave

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, February 14, 2008 8:03 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Noob Question (Ignore if the question insults)

While I have no knowledge that this is the case, I would GUESS that explication for the change is almost certainly that Intel objected to the use of their competitor’s moniker in the build environment.

Believe it or not, I have known some Intel folks to be very touchy about the “AMD64” designation for any x64 Windows build.

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

11

Well I am certainly glad that I am not alone in discerning the inconsistent
cavalier arrogant and S T U P I D quality of this perfidious change. All
over the planet (or in the 12 or so organizations that actually do serious
windows driver development outside of Microsoft) people are fixing up build
systems to deal with yet another WDK peculiarity.

So ddkbuild.bat will, for now, key off the unique to 6001 xml version file
to figure out which incantation to use for the two Vista Era WDKs. This
should allow the use of either one without the user having to specify which
one he/she/it is actually using. Ugh. Nice that. That is twice in one day
I’ve had to fix this in two different build systems.

On Thu, Feb 14, 2008 at 8:54 PM, David R. Cattley wrote:

> And yet it seems the marchitects only partially succeeded since it would
> appear that everywhere except the SETENV arguments still refer/use amd64.
> So such a petty and useless move without maintaining backward
> compatibility by keeping amd64 as a valid SETENV flag results in just
> aggravation. Now all of those build scripts that could use a single token
> (amd64) to drive their behavior have to pick and chose by context when to
> use amd64 and x64. Noting of course the $(AMD64) still persists as is,
> $(TARGET_DIRECTORY) remains amd64, etc. etc. etc. That is a awfully thin
> bit if paint to apply. Can we expect that next the INF syntax will change,
> that all the build environment will no longer define _AMD64?
>
> Would it have been such a huge problem if the DDK Team had added x64 to
> make the market whiners happy and kept amd64 so we could have a simple (aka,
> no work, no fuss, no mess) transition to the new WDK from the perfectly fine
> previous version?
>
> As if the population of the planet that uses the DDK will really be swayed
> by this clever bit of eradication of AMD from the SETENV arguments and
> somehow conveniently forget that we need to have ‘that other CPU family’ in
> the stable for testing too.
>
> I am so glad tomorrow is Friday. It’s time for my medication.
> -dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
> Sent: Thursday, February 14, 2008 8:03 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Noob Question (Ignore if the question insults)
>
>


>
> While I have no knowledge that this is the case, I would GUESS that
> explication for the change is almost certainly that Intel objected to the
> use of their competitor’s moniker in the build environment.
>
> Believe it or not, I have known some Intel folks to be very touchy about
> the “AMD64” designation for any x64 Windows build.
>
> 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
>
>
> —
> 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
>

–
Mark Roddy

12

perfidious - good word

S T U P I D - still better.

mm

Mark Roddy wrote:

Well I am certainly glad that I am not alone in discerning the
inconsistent cavalier arrogant and S T U P I D quality of this
perfidious change. All over the planet (or in the 12 or so organizations
that actually do serious windows driver development outside of
Microsoft) people are fixing up build systems to deal with yet another
WDK peculiarity.

So ddkbuild.bat will, for now, key off the unique to 6001 xml version
file to figure out which incantation to use for the two Vista Era WDKs.
This should allow the use of either one without the user having to
specify which one he/she/it is actually using. Ugh. Nice that. That is
twice in one day I’ve had to fix this in two different build systems.

On Thu, Feb 14, 2008 at 8:54 PM, David R. Cattley > mailto:xxxxx> wrote:
>
> And yet it seems the marchitects only partially succeeded since it
> would appear that everywhere except the SETENV arguments still
> refer/use amd64. So such a petty and useless move without
> maintaining backward compatibility by keeping amd64 as a valid
> SETENV flag results in just aggravation. Now all of those build
> scripts that could use a single token (amd64) to drive their
> behavior have to pick and chose by context when to use amd64 and
> x64. Noting of course the $(AMD64) still persists as is,
> $(TARGET_DIRECTORY) remains amd64, etc. etc. etc. That is a awfully
> thin bit if paint to apply. Can we expect that next the INF syntax
> will change, that all the build environment will no longer define
> _AMD64?
>
> Would it have been such a huge problem if the DDK Team had added x64
> to make the market whiners happy and kept amd64 so we could have a
> simple (aka, no work, no fuss, no mess) transition to the new WDK
> from the perfectly fine previous version?
>
> As if the population of the planet that uses the DDK will really be
> swayed by this clever bit of eradication of AMD from the SETENV
> arguments and somehow conveniently forget that we need to have ‘that
> other CPU family’ in the stable for testing too.
>
> I am so glad tomorrow is Friday. It’s time for my medication.
> -dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> mailto:xxxxx
> [mailto:xxxxx@lists.osr.com
> mailto:xxxxx] On Behalf Of
> xxxxx@osr.com mailto:xxxxx
> Sent: Thursday, February 14, 2008 8:03 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Noob Question (Ignore if the question insults)
>
>


>
> While I have no knowledge that this is the case, I would GUESS that
> explication for the change is almost certainly that Intel objected
> to the use of their competitor’s moniker in the build environment.
>
> Believe it or not, I have known some Intel folks to be very touchy
> about the “AMD64” designation for any x64 Windows build.
>
> 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
>
>
> —
> 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
>
>
>
>
> –
> Mark Roddy</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

13

What is really STUPID about the setenv change is how badly they did it. If
you get an error message from the script it still refers to the mode as
AMD64. It would have been a one line addition to support the old option
for backwards compatibility and the new switch. Whoever did the change,
should not be allowed near drivers.

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

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> perfidious - good word
>
> S T U P I D - still better.
>
> mm
>
> Mark Roddy wrote:
>> Well I am certainly glad that I am not alone in discerning the
>> inconsistent cavalier arrogant and S T U P I D quality of this
>> perfidious change. All over the planet (or in the 12 or so organizations
>> that actually do serious windows driver development outside of Microsoft)
>> people are fixing up build systems to deal with yet another WDK
>> peculiarity.
>> So ddkbuild.bat will, for now, key off the unique to 6001 xml version
>> file to figure out which incantation to use for the two Vista Era WDKs.
>> This should allow the use of either one without the user having to
>> specify which one he/she/it is actually using. Ugh. Nice that. That is
>> twice in one day I’ve had to fix this in two different build systems.
>>
>> On Thu, Feb 14, 2008 at 8:54 PM, David R. Cattley >> mailto:xxxxx> wrote:
>>
>> And yet it seems the marchitects only partially succeeded since it
>> would appear that everywhere except the SETENV arguments still
>> refer/use amd64. So such a petty and useless move without
>> maintaining backward compatibility by keeping amd64 as a valid
>> SETENV flag results in just aggravation. Now all of those build
>> scripts that could use a single token (amd64) to drive their
>> behavior have to pick and chose by context when to use amd64 and
>> x64. Noting of course the $(AMD64) still persists as is,
>> $(TARGET_DIRECTORY) remains amd64, etc. etc. etc. That is a awfully
>> thin bit if paint to apply. Can we expect that next the INF syntax
>> will change, that all the build environment will no longer define
>> _AMD64?
>>
>> Would it have been such a huge problem if the DDK Team had added x64
>> to make the market whiners happy and kept amd64 so we could have a
>> simple (aka, no work, no fuss, no mess) transition to the new WDK
>> from the perfectly fine previous version?
>>
>> As if the population of the planet that uses the DDK will really be
>> swayed by this clever bit of eradication of AMD from the SETENV
>> arguments and somehow conveniently forget that we need to have ‘that
>> other CPU family’ in the stable for testing too.
>>
>> I am so glad tomorrow is Friday. It’s time for my medication.
>> -dave
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> mailto:xxxxx
>> [mailto:xxxxx@lists.osr.com
>> mailto:xxxxx] On Behalf Of
>> xxxxx@osr.com mailto:xxxxx
>> Sent: Thursday, February 14, 2008 8:03 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] Noob Question (Ignore if the question insults)
>>
>>


>>
>> While I have no knowledge that this is the case, I would GUESS that
>> explication for the change is almost certainly that Intel objected
>> to the use of their competitor’s moniker in the build environment.
>>
>> Believe it or not, I have known some Intel folks to be very touchy
>> about the “AMD64” designation for any x64 Windows build.
>>
>> 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
>>
>>
>> —
>> 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
>>
>>
>>
>>
>> –
>> Mark Roddy
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

14

Well, at least it’s still the case that USERNAME=WinDDK.

mm

Don Burn wrote:

What is really STUPID about the setenv change is how badly they did it. If
you get an error message from the script it still refers to the mode as
AMD64. It would have been a one line addition to support the old option
for backwards compatibility and the new switch. Whoever did the change,
should not be allowed near drivers.

15

Don’t get me started.

On Fri, Feb 15, 2008 at 12:01 PM, Martin O’Brien
wrote:

> Well, at least it’s still the case that USERNAME=WinDDK.
>
> mm
>
> Don Burn wrote:
> > What is really STUPID about the setenv change is how badly they did it.
> If
> > you get an error message from the script it still refers to the mode as
> > AMD64. It would have been a one line addition to support the old
> option
> > for backwards compatibility and the new switch. Whoever did the change,
> > should not be allowed near drivers.
> >
> >
>
> —
> 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
>

–
Mark Roddy