Mark,
Mark, I’m not criticizing ddkbuild! It’s obviously a nice piece
of software, because lots of people use it and are happy with
it.
I’m just saying that VS.NET brings in new features that make
things easy if they’re well used. And I’m also making the point
that it is perfectly possible to use the VS.NET IDE and still do
it so that what really happens is precisely the same that
happens when you run from a CMD box: you set up your sources
file, make your makefile point to makefile.def, run build.exe to
cause compiling and linking to be done with the DDK tools.
VS.NET ends up doing exactly the same thing we do on the command
line, but it adds the wealth of choices and nice features of the
IDE.
My machine at work is an SMP and this stuff works, remember, I’m
using build.exe and the DDK compiler and linker just like
everyone else. I’m still running build.exe on a cmd box to cause
the DDK compiler and linker to build my drivers, the only
difference is that I set up VS.NET between myself and the cmd
box so that I never have to type commands into the box: I use
the IDE instead and if bad comes to worse I can always resort to
the command window. VS.NET has extensive source browsing, I just
tried it on one of my Makefile Projects and it seems to work
fine, and I can use Whole Tomato on top of it.
Actually, in that line, there’s something I don’t quite
understand. I have looked at the C compiler versions for the
DDKs and IDEs I have installed in my machine at home, and this
is what I found:
DDK 2260: CL Version 13.00.9176
VC7 2002: CL Version 13.00.9466
VC7 2003: CL Version 13.10.3077
DDK 3790.1830: CL Version 13.10.4035
I don’t have VC7 2005 installed nor do I use the other DDKs, so,
I couldn’t check their compiler versions. Now, about “old
compilers”, note that DDK 2260 uses a 13.00 compiler, which I
must believe is older than the 13.10.3077 compiler used in VC7
2003. My naive conclusion is that anything that compiles fine
under 13.00.9176 should compile fine under 13.10.3077, no ? Now,
one could argue that the 13.10.4035 compiler that ships with the
current Win2k3 SP1 DDK is newer than the VC7 2003 compiler, but
I may bet that VC7 2005 ships with a compiler that’s even newer
than the 13.10.4035 version. Which will mean that there should
be no problem using VS.NET 2005 to compile and link drivers.
Unless of course Microsoft’s compiler group generates special
compilers and linkers with special features to make driver
builds work, but do they really do that ? It doesn’t quite make
sense from a compiler writing standpoint, nor does it make much
business sense to allow such a small target market such as
driver writing demand special compiler features that could
easily be avoided by taking a little bit more care in specifying
one’s APIs and libraries. But hey, anything’s possible.
In fact, I found through personal experience that the correct
compiler/linker/lib pairing is way more important than the
compiler level, but hey, I could be wrong because most of the
drivers I worked with were either display/graphics/3D drivers or
down-at-the-machine-level stuff such as BoundsChecker and
TrueCoverage, and those aren’t quite your off-the-shelf WDM
drivers that a lot of ntdev posters write for a living.
Last but not least, again, I’m not criticizing ddkbuild! A lot
of people use it and they’re happy with it, so, it must be a
good tool. All I’m saying is that phrases such as “you must use
the ddk compiler” or “if you don’t use build.exe you insert
subtle errors” are no excuse for not using the IDE. Also, I make
a point of trying to never criticize a colleague’s software, so,
forgive me if I gave you that impression - and I apologize to
you if that’s what happened!
Alberto.
----- Original Message -----
From: “Mark Roddy”
To: “Windows System Software Devs Interest List”
Sent: Saturday, July 23, 2005 10:12 PM
Subject: RE: Re:[ntdev] Compiler version not supported by
Windows DDK.
Yes of course you are right alberto. There couldn’t possibly be
anything
else to it.
Have you tried that on an mp machine? Ooops, error linkage in VS
won’t work.
Have you tried to get bscmake to run so that you can use source
browsing? It
won’t with that ddk, it will with ddkbuild which happens to know
about the
undocumented command line argument for turning bscmake support
back on.
There is a reason why ddkbuild has been out there for almost 10
years. Is
there some reason why you seem to think it is the wrong way to
go?
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alberto
> Moreira
> Sent: Friday, July 22, 2005 11:05 PM
> To: Windows System Software Devs Interest List
> Subject: Re: Re:[ntdev] Compiler version not supported by
> Windows DDK.
>
> Ok, the details.
>
> 1. Set up an auxiliary batch file. Call it drvbuild.bat:
>
> call %winddk%\bin\setenv %winddk% chk wnet
> devenv
>
> Of course %winddk% is your ddkroot, say, c:\winddk\3790.1830,
> and devenv.exe’s directory is in your path.
>
> 2. Setup a link on your desktop, for properties put something
> like
>
> “%windir%\system32\cmd /k
> %yourexecutabledirectory%\drvbuild.bat”
>
> Now every time you click on that icon you get an msvc.net
> shell with all the ddk environment set up. Or, if you’re
> lazy, just bring up the checked or free cmd window of your
> preference, type “devenv” at the prompt and press enter.
>
> 3. Bring up your devenv.exe. Click File/New/Project/Visual
> C++ Projects. Choose “Makefile Project”.
>
> 4. Set your path and project name, click “ok”.
>
> 5. Click “Application Settings”.
>
> 6. Enter your settings:
>
> 6a. Your build command line is "%windir%\bin\x86\build.
> 6b. Your output is whatever your driver’s name happens to
> be.
> 6c. Your clean commands are whatever you need to wipe out
> your obj files.
> 6d. Your rebuild command line is
> “%windir%\bin\x86\build -c”
>
> Note that if you just leave these fields blank you can set
> them in your Project/Properties window, which allows you to
> enter multiple lines for each command: you can add debugging
> information and other stuff if you feel like.
>
> 7. Now your project’s up. Go Tools/Options/Projects/VC++
> Directories and add your %windir%\bin\x86 directory to the
> top of the executable list. That will make sure you use the
> DDK compiler and linker when you build. If you’re
> supersticious, also add %windir%\bin to the executable list.
>
> 8. Now go Project/Properties and tweak your settings. Don’t
> forget to set them up for the Release build too. Also set
> your debugging so that if you press F5 or F10, the debugger
> goes directly to the top of your app (which, of course, you
> will have set up as another project inside the same
> solution!) Also, at this time you will want to add your own
> include and lib directories to the
> tools/options/projects/VC++ Directories lists.
>
> 9. Add your source files to your project as you need them.
> Add your “sources” file to it too, you may need to tweak it
> here or there. Also, consider splitting parts of your driver
> into a DRIVER_LIBRARY component, it often helps.
>
> 10. Now your environment is ready to be tested! Click on your
> “build sys” or “build solution” button, and you will get the
> IDE to build your driver using your sources, your
> makefile/makefile.inc as you feel fit, using build.exe and
> the ddk compiler and linker.
>
> There’s a zillion variations around this theme, and you can
> set yourself up with other kinds of projects too, but this
> one is very, very easy: it takes about five to ten minutes
> work to set yourself up.
>
> I have also done this on occasion: build the driver once with
> build.exe, fish out the log, pull out the command line into a
> file, and get the shell to use the file as the source of its
> command line switches and variables to the C++ compiler. Or
> you can set up an utility project, that works too.
>
> I also call your attention to what I call the “asterisk
> notation” property of your sources file, where you can have
> build.exe automatically insert your architecture string (such
> as “i386”, “amd64”, etc.) in your directory and/or file names.
> Comes in handy at times!
>
> Alberto.
>
>
>
>
>
> ----- Original Message -----
> From: “Mark Roddy”
> To: “Windows System Software Devs Interest List”
>
> Sent: Friday, July 22, 2005 7:41 AM
> Subject: RE: Re:[ntdev] Compiler version not supported by
> Windows DDK.
>
>
> Invoking build.exe directly is insufficient as build.exe
> depends on the environment set up by the setenv.bat script
> that comes with the ddk. That script in turn requires
> specific command line arguments. The appropriate command line
> arguments to setenv.bat change from release to release. The
> ‘10 line shell script’, done correctly is more like 100-200
> lines.
> Thus the
> venerable ddkbuild.bat, which has managed to do this
> correctly (more or less, your mileage may vary) since 1996.
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032 www.hollistech.com
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
> Alberto Moreira
> > Sent: Thursday, July 21, 2005 10:47 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: Re:[ntdev] Compiler version not supported by
> Windows DDK.
> >
> > With all due respect to Hollistech and to OSR, you need zero
> > third
> > party software here.
> >
> > Point your IDE to the DDK compiler, setup a project for
> your driver -
> > the settings are irrelevant - setup a custom build step
> that invokes
> > build.exe (or set it up so that you can reach it from
> tools/external
> > tools, or if you’re really fastidious set up a build button
> > on a
> > toolbar), and setup an icon on your desktop to run
> > DEVENV.EXE from
> > inside a checked or free build cmd
> > prompt: done. Takes what, five minutes work ?
> >
> > Also, no driver lives alone: one often needs applications,
> > and it’s
> > nice to have both projects under the same IDE workspace so
> > that if
> > nothing else they can share include files and the like.
> > And if you really want to pig out, you can write a ten-line
> > script
> > that runs build.exe to build your driver but the full IDE
> > build to
> > make the app, link it to your build button, again, done.
> >
> > Use the IDE, dude.
> >
> > Alberto.
> >
> >
> >
> > ----- Original Message -----
> > From: “Gary G. Little”
> > Newsgroups: ntdev
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Thursday, July 21, 2005 10:18 AM
> > Subject: Re:[ntdev] Compiler version not supported by
> > Windows DDK.
> >
> >
> > > Instead of wasting time mucking around with the IDE, spend
> > your time
> > > developing your driver code. Get DDKBUILD either from
> > > www.hollistech.com or www.osronline.com and use the IDE
> to create a
> > > MAKEFILE project. That will work across any version of
> > Visual Studio
> > > including the 2005 beta 2.
> > >
> > > –
> > > The personal opinion of
> > > Gary G. Little
> > >
> > > “Jussi Rytilahti” wrote in
> > > message
> > > news:xxxxx@ntdev…
> > >> Hi,
> > >>
> > >> I am total newbie with drivers. I have one problem. I am
> > >> reading
> > >> Walter Oneys book “Programming the Microsoft Windows
> Driver Model,
> > >> Ed2” and now I´d like to try his AppWizard for Visual C++
> > >> 6.0
> > >> (WDMWIZ.AWX). I get every time same error :
> > >> error C1189: #error : Compiler version not supported by
> > Windows DDK.
> > >> I am using DDK 2600.1106 and working OS is XP.
> > >> Documentation of this wizard says that wizard is for
> > VC++6.0 and XP
> > >> and .NET DDKs
> > >>
> > >> Do I have any chances to use VC++6.0 with my DDK? (I have
> > also .NET,
> > >> but wizard works only in 6.0)
> > >>
> > >> BR.
> > >> Jussi
> > >>
> > >>
> > >
> > >
> > >
> > > —
> > > 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
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to
> xxxxx@lists.osr.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@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com