... 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 manualSkybuck Flying said: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.
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.Skybuck Flying said:I installed DDKBUILD in:
The DDKWizard assumes it's in C:\WINDDK so the wizard can't find it.
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).Skybuck Flying said:Further more my WDK is in:
This also has to be overriden in the wizard options.
Now that is feedback you could have sent me, for example ... because if I "fix" it, people may have it easier to use DDKWizard.Skybuck Flying said:To do this simply check the disabled-looking checkboxes... they are not
really disabled... they just look like that...
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.Skybuck Flying said:That's a gui design mistake by the creator of the wizard.
For the first text field that's correct. It's even described like that.Skybuck Flying said: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:
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?Skybuck Flying said:It creates to project though... apperently one for windows xp and one for
longhorn or so...
That's kinda weird.
It's weird, but Microsoft indeed produced already DDKs for NT4 ...Skybuck Flying said:So tool seems a bit old but ok.
... which DDKBUILD nicely circumvents by using the short path and file names (which by definition never contain blank spaces).Skybuck Flying said: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.
Cool, so you'd be fine with DDKBUILD, but not when using the tools from the WDK directly.Skybuck Flying said: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...
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.Skybuck Flying said:Big question is when will all these compilers finally support spaces in
paths and filenames ?!?
True, because in 1992 people would have read the documentation that comes with a program, you know?!Skybuck Flying said:This is not 1992 with dos you know ?!
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.