Peter Viscarola wrote:
It’s not perfect, mind you. You still have the problem of changes to
environment variables and compiler/linker options that occur on updates to
the DDK. If I import my project to VS today, and install the XP SP 1 DDK
tomorrow, how do I update my project to use all the new stuff (headers,
libs, compiler, linker, switch settings) in that new DDK?
Another 2 cents worth here: The FIXPROJ.EXE that’s in my service pack
and that will be in the 2d edition samples will change the settings in
an entire directory tree worth of VS project files according to a
profile. I build the profiles by capturing the BUILD log through a
wizard that’s built into FIXPROJ. This is how I update project settings
when the DDK changes. Mind you, I *do* heartily wish it would *stop*
changing and that Microsoft would document the compiler and linker
settings that are needed – if they can. I’ll bet they don’t even know
why all of the #define’s need to be there any more.
And I guess I’m not sure how you support things like deprecated function
reporting or other such features in the DDK that require setting environment
variables in order to enable them. Do ya just set the environment variable
before starting VS (like msdev.exe/userenv as Bi did)?
Personally, I do that in my source files – specifically the “stddcls.h”
that I include in every file. The environment variable just triggers a
-D option that’s the same as a #define.
One of the reasons I tried to force my readers to switch the XP DDK
(apart from getting them to use the DDK compiler) was to get the
deprecated function stuff. For that, they have to build in the XP
environment no matter what the target is. But, of course, the driver
will still be cross-platform compatible if people are careful which
functions they call.
There’s another issue, too, though I sort of hate to mention it (it’s an
entirely different point than the one we’ve been discussing). But,
anyhow… Not having a standard build environment that everyone uses makes
it very hard to add new features to the DDK and have those features
universally adopted. Microsoft can’t possibly support, or even anticipate,
every build environment. You can say “well, if the feature or tool is
compelling enough, people will use it.” But the fact is that the build
environment for anything beyond a “hello world” driver is complex enough
that it can take an experienced engineer many hours to get their stuff
building right in a different environment. And they’re gonna do this to TRY
OUT some new tool or functionality just to see if it’s gonna help them? I
don’t think so.
So, how about just picking Visual Studio in some incarnation, that being
the standard build environment for every other thing you do with
Microsoft tools. Seems to me that the biggest software company in the
solar system (so far as we know, that is) should be able to accomplish
that given that so many people want it.
–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com