Max,
I have worked a lot with integrated applications where the
system spans from the GUI to the iron. My experience is that
apps are usually way larger, way more complex and way harder to
maintain than drivers, yet I don’t think anyone would in his or
her right mind suggest that people build apps with build.exe.
And they’re more often than not generated from an initial Wizard
run. It’s close to nonsense to write an MFC app from scratch,
when you can get so much ancillary code written in five minutes
of point and click! It’s even more apparent with .NET, because
it has extensive facilities for on-line point-and-click
generation of working industrial-strength code. I only wish
Microsoft included driver writing in that environment!
DriverWorks and DriverNetworks are a step in the right
direction, but there’s much more to be achieved.
In fact, apps are usually organized in projects, and the IDE
gives us automatic management of project dependencies and of
different configurations, such as x86, amd64 or i64, checked or
free. The IDE gives us a powerful debugger (and it’s a pity that
Microsoft didn’t integrate a kernel debugging capability from
within the IDE debugger), a rather effective object browser (and
you can go to Whole Tomato, or write your own addin, if you want
something even better), integration with the Source Control
System, automatic generation of XML documentation, integration
with Web deployment, the ability to integrate my own code into
the IDE through macros, addins, or merely by inserting the tool
into the external tools menu, and a lot more.
Apps are usually way more complex and way bigger structures than
drivers, and yet everybody uses the IDE for their development.
For production, all you have to do is to add one line to your
build script, which calls the IDE:
DEVENV /run “c:\mydirectory\mysolution.sln”
That can be safely done by the release management team, no need
for developers to bother about that except in very small
organizations where the developer has to wear both hats.
Moreover, the IDE lets you operate on an “experimental” branch
of your tree until it’s time to move up to production, at which
time changing one registry entry does the trick: it can’t get
simpler than that.
If you generate your code the right way, the IDE build
environment builds up automatically, with near zero delta
effort. No need to bother about makefiles, sources files, script
files or the like: you build the solution as you go, by point
and click, and all its management is done either automatically
or with point and click.
Now, about Prefast, DV and the rest, I might even use it, if
they were integrated with the IDE. But I’m a minimalist myself,
and I don’t see much use for that kind of tool; a healthy degree
of separation between my code and the API, a large amount of
caring for the computer science base underneath the program I
write, and enough knowledge of the hardware, well those have
been enough for my own development; one of my self-discipline
rules is, I don’t use anything unless I really, really have to.
Besides, my specialty is graphics, what do DriverVerifier or DV
know about Texture Mapping or about 3D graphics pipelines ?
These tools useless to me, my industry has its own benchmarks
and tests.
Know computer science, know your hardware, minimize your
interactions with outside software, that’s my advice. And do not
write any script of any source if you can avoid it; there’s
enough technology out there that the command box should be
delegated to the museum where it belongs.
Alberto.
----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Saturday, June 18, 2005 7:02 AM
Subject: Re: [ntdev] build environment for 64 bit driver -
general questions
>> 1. Driver building is a nearly unmaintainable mess today,
>> and
>> the judicious use of an IDE goes a long way towards
>> alleviating
>> it.
>
> IDE builds are by far more messy then BUILD.EXE. That’s why MS
> uses BUILD for
> the OS itself.
>
>> write. If you achieve that, tools such as Driver Verifier or
>> PreFast can be quite irrelevant: do you job thoroughly and
>> carefully and you don’t need props.
>
> The human attention is limited, so, even the good specialist
> can make typo-like
> bugs. So, PreFast and DV are very, very valuable.
>
>> THE CONCEPT OF WIZARD-DRIVEN PROGRAM GENERATION AND
>>DEVELOPMENT,
>> COMMONPLACE IN MFC AND IN .NET, IS NOT SUPPORTED IN
>> DRIVERLAND.
>
> This is a stupid novice-only demo-like thing in userland too.
> Not suitable for
> anything complex and non-linear.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
