???

Ok,

I got it working with DDKBuild.CMD.

Apperently the problem seems to be with the path to the DDKBUILD.CMD when
the project is setup from within visual studio 2008.

I installed DDKBUILD in:

C:\Tools\DDKBUILD

The DDKWizard assumes it's in C:\WINDDK so the wizard can't find it.

Further more my WDK is in:

C:\Tools\WinDDK\6001.18001

This also has to be overriden in the wizard options.

To do this simply check the disabled-looking checkboxes... they are not
really disabled... they just look like that...

That's a gui design mistake by the creator of the wizard.

I setup the path to point directly to the cmd tool and then it works... just
specifieing the folder for the bat approach didn't see to work... the path
and filename must be specified like so:

C:\Tools\DDKBUILD\DDKBUILD.CMD

Now the building for the example drivers works in visual studio 2008... nice
!

It creates to project though... apperently one for windows xp and one for
longhorn or so...

That's kinda weird.

So tool seems a bit old but ok.

Euhm... also I read some of the WDK documentation and it appears the build
tools and possibly the cl.exe compiler has problems with "spaces" in
filenames and paths.

So filenames and paths should not contain spaces...

I find this very annoying and limiting... because all of my development
folders usually contain plenty of spaces...

But to be on the safe side and prevent problems later on it's better to
avoid spaces in filenames and paths all together.

Big question is when will all these compilers finally support spaces in
paths and filenames ?!?

This is not 1992 with dos you know ?!

Bye,
Skybuck.

Apperently the two projects use the same code... so that's good.

So apperently these are two different projects for compiling on different
platforms or so

Bye,
Skybuck.

[Assarbad]

Originally Posted by Skybuck Flying

Ok,

I got it working with DDKBuild.CMD.

Apperently the problem seems to be with the path to the DDKBUILD.CMD when
the project is setup from within visual studio 2008.

... consulting the manual up front sometimes really helps. The current manual has 29 pages and I haven't put all this effort into it so people argue about problems that wouldn't exist if they had read the manual

Originally Posted by Skybuck Flying

I installed DDKBUILD in:

C:\Tools\DDKBUILD

The DDKWizard assumes it's in C:\WINDDK so the wizard can't find it.

DDKWizard makes no such assumptions. See section 1.1, point 4 of the list. You will have to either add the location that your ddkbuild.cmd resides into your PATH environment variable (may require restarting VS or even the computer, depending whether you change the user or system profile) or into the Visual Studio settings.

Originally Posted by Skybuck Flying

Further more my WDK is in:

C:\Tools\WinDDK\6001.18001

This also has to be overriden in the wizard options.

Does it now? How about setting the WLHBASE environment variable instead and enjoying its effect globally within your profile?! Of course, some people keep a particular version of a DDK/WDK in their version control system alongside their project, so they want to override this option, which can be done through the property sheet or through the use of ddkbldenv.cmd ... (where the latter one will also work flawlessly from the command line).

Originally Posted by Skybuck Flying

To do this simply check the disabled-looking checkboxes... they are not
really disabled... they just look like that...

Now that is feedback you could have sent me, for example ... because if I "fix" it, people may have it easier to use DDKWizard.

Originally Posted by Skybuck Flying

That's a gui design mistake by the creator of the wizard.

Thanks for the "compliment" and also "thanks" for not reporting it to me directly. It's not as if the contact option isn't given anywhere, is it? It's always good to get positive feedback after putting many hours into something that is then offered free of charge for anyone.

Originally Posted by Skybuck Flying

I setup the path to point directly to the cmd tool and then it works... just
specifieing the folder for the bat approach didn't see to work... the path
and filename must be specified like so:

For the first text field that's correct. It's even described like that.

Originally Posted by Skybuck Flying

It creates to project though... apperently one for windows xp and one for
longhorn or so...

That's kinda weird.

Oh yeah? What did I say about reading the manual again? Maybe I should have written it in my native language instead of making it easy? Would that have sparked your interest?

Originally Posted by Skybuck Flying

So tool seems a bit old but ok.

It's weird, but Microsoft indeed produced already DDKs for NT4 ...

So if you had read the manual or even just a few of the hints/tooltips in the wizard itself, you'd know that the WXP project was created for use with a Windows XP DDK, while a WLH project would be created for use with a Windows Vista/2008 Server WDK.

Originally Posted by Skybuck Flying

Euhm... also I read some of the WDK documentation and it appears the build
tools and possibly the cl.exe compiler has problems with "spaces" in
filenames and paths.

... which DDKBUILD nicely circumvents by using the short path and file names (which by definition never contain blank spaces).

Originally Posted by Skybuck Flying

So filenames and paths should not contain spaces...

I find this very annoying and limiting... because all of my development
folders usually contain plenty of spaces...

Cool, so you'd be fine with DDKBUILD, but not when using the tools from the WDK directly.

Probably you haven't even noticed the worst limitation I have found. Try reference files from subsubfolders or anything that isn't parent or current folder from the perspective of a SOURCES file. Good luck!

Originally Posted by Skybuck Flying

Big question is when will all these compilers finally support spaces in
paths and filenames ?!?

Interestingly the compilers do, so do several other tools. But some parts have this limitation and MS was (is?) reportedly using the same system to build the whole OS. So it seems to work for some people.

Originally Posted by Skybuck Flying

This is not 1992 with dos you know ?!

True, because in 1992 people would have read the documentation that comes with a program, you know?!