“Walter Oney” wrote in message news:xxxxx@ntdev…
>
> 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.
>
Walt… come on. There’s no way to keep the build environment static. It’s
neither possible nor even desireable. For example, to get the deprecated
function support that you like (more about that below) required the new
compiler version. Likewise, buffer-overrun checking, etc. Not to mention
support for the continuously evolving “x86” instruction set (whatever that
means these days).
> 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.
Well, that is coincidentally true for the deprecated function stuff. But
there’s no reason that it HAS to be that way (that’s just happens to be the
way I implemented it, to be perfectly honest).
> 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
>
or later, right…
>
> 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.
>
Well, there are a couple of problem with chosing Visual Studio:
1) As David Craig mentioned a few posts back, all of Windows is built using
“build”. There are a lot of reasons for this – Some purely historical, and
some still extremely valid. For example, think you could build a project
the size of Windows in VS? I think not. Think MS wants to gate the tools
used to build their operating system on when the GUI that front-ends the
compiler is available? Why would they do that? In any case… it’s a given
that Windows will be built with the command line version of the compiler,
and that the entire Windows division isn’t going to switch to using VS.
2) That brings us to the DDK. What I think is most important in the DDK (as
a build environment) is having a stable, reliable, platform that maximizes
your chances of buildiing a driver that works properly with the targeted
plaform(s). Sooooo, what you probably want to do is make the DDK build
environment mimic as closely as possible the environment used to build the
operating system. It actually does this remarkably well and it’s not as
easy as it looks. It would be pretty complicated to have the DDK based on
VS, while the O/S itself is built using build. Think of just the complexity
required to get samples into the DDK? Could MS be sure that building stuff
in VS is doing the same thing as build, or would they have to re-test every
single sample driver built with VS?
It’s all very complicated. It’s incredibly easy to wave your hands and say
“just do” this and that. When you look at the reality of doing it, it’s much
easier said than done.
P